NEWS
Untersuchung: code 25 fehlerlösung
-
Das sag ich ja auch schon geraume Zeit...
Mit dem node-red-Adapter kommen die Probleme.@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
Das sag ich ja auch schon geraume Zeit...
Mit dem node-red-Adapter kommen die Probleme.Ich kann nur immer wieder betonen - ich habe Null Probleme, seit dem ich das ganze node_modules Verzeichnis weggeschmissen und wieder habe neu aufbauen lassen. Und in meinen Augen hat das nichts mit NodeRed zu tun. Mag zwar sein, dass es hier - weil mehr als nur eine Bibliothek installiert wird, der Fehler häufiger auftaucht - aber mE hat das was mit alten Versionen in dem node_modules Verzeichnis zu tun, die neu aufgebaut werden müssen. Es scheint aber wohl eine Eigenschaft von npm zu sein, diese alte module nicht wegzuschmeissen, sondern in "."-Verzeichnissen zu sichern. Wenn man nur diese "." - also Backup-Verzeichnisse aufräumt - ist das halt nicht in jeder Umgebung ausreichend.
-
@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
Mit dem node-red-Adapter kommen die Probleme.
Kann aber nicht sein an sich weil ja schon die Installation des node-red auf die schnauze fällt ... es muss also davor passiert sein ... oder?!
@apollon77
Ja und nein. Auffällig ist ja, dass wenn ich die Korrektur rennen lasse und dann adapter installiere es genau so lange gut geht bis ich wieder Node-Red 4.0 versucht habe. danach ging es nicht mehr. Dann wieder die Korrektur laufen lassen und dann gingen die Adapter wieder. Mittlerweile ist auch nodered 4 installiert und es scheint jetzt wieder zu laufen.Klar kann irgendwas altes oder auch etwas anderes der Grundauslöser sein. Aber das war nur meine Beobachtung. Mal schauen was passiert wenn es wieder adapter updates gibt.
-
@apollon77
Ja und nein. Auffällig ist ja, dass wenn ich die Korrektur rennen lasse und dann adapter installiere es genau so lange gut geht bis ich wieder Node-Red 4.0 versucht habe. danach ging es nicht mehr. Dann wieder die Korrektur laufen lassen und dann gingen die Adapter wieder. Mittlerweile ist auch nodered 4 installiert und es scheint jetzt wieder zu laufen.Klar kann irgendwas altes oder auch etwas anderes der Grundauslöser sein. Aber das war nur meine Beobachtung. Mal schauen was passiert wenn es wieder adapter updates gibt.
@mikehak Also Formal für die die die Issues haben wäre cool VOR und NACH jedem Adapter update mal das Skript laufen zu lassen - ABER das was nur loggt (da gabs auch mal ne variante). Dann sollte man ja sehen können wann da was stehenbleibt
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@mikehak Also Formal für die die die Issues haben wäre cool VOR und NACH jedem Adapter update mal das Skript laufen zu lassen - ABER das was nur loggt (da gabs auch mal ne variante). Dann sollte man ja sehen können wann da was stehenbleibt
@apollon77 sagte in Untersuchung: code 25 fehlerlösung:
ABER das was nur loggt (da gabs auch mal ne variante).
Die kindersichere Version (ohne Löschen):
for i in $(find /opt/iobroker/node_modules -type d -iname ".*-????????" ! -iname ".local-chromium"); do echo ${i%/}; done -
@apollon77 sagte in Untersuchung: code 25 fehlerlösung:
ABER das was nur loggt (da gabs auch mal ne variante).
Die kindersichere Version (ohne Löschen):
for i in $(find /opt/iobroker/node_modules -type d -iname ".*-????????" ! -iname ".local-chromium"); do echo ${i%/}; doneWar mal wieder soweit. 7 Adapter standen zum update an und da morgen Feiertag ist... ;-)
Vlt können die Erfahrungen zur Fehlersuche beitragen. Jedenfalls hatte ich bei allen 7 Adaptern nachvollziebar das gleiche Fehlerbild. Bin wie folgt vorgegangen:
- temp Dateien gelöscht. das es ohne nicht geht, habe ich letztens schon erfahren müssen.
iobroker@iobroker:~$ for i in $(find /opt/iobroker/node_modules -type d -iname ".*-????????" ! -iname ".local-chromium"); do rm -rf ${i%%/}; done- Adapter Update z.B.:
iobroker@iobroker:~$ iob upgrade pushover@3.0.3 --debugUnd jetzt wird es interessant. Fehler:
npm ERR! code ENOTEMPTY npm ERR! syscall rename npm ERR! path /opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src npm ERR! dest /opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src npm ERR! errno -39 npm ERR! ENOTEMPTY: directory not empty, rename '/opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src' -> '/opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src'Und zwar bei allen 7 Adaptern IMMER das gleiche Verzeichnis.
-
Nochmal gelöscht. siehe 1.
-
Nochmal update. siehe 2.
Und beim 2.ten mal lief das Update jedesmal ordentlich durch! Und das nachvollziehbar bei jedem der 7 Adapter.
Was hab ich sonst noch getestet?
Da das angemeckerte Verzeichnis ein Node-red Verzeichnis ist, habe ich den NR-Adapter mal vor dem Update gestoppt. Hatte keine Auswirkungen.Den einzigen Unterschied, den ich zwischen den jeweils ersten Update-Versuch und dem nachfolgenden erfolgreichen gesehen habe, war die Tatsache, dass der Adapter nach dem ersten Versuch natürlich gestoppt war.
Also habe ich testweise beim nächsten Adapter diesen vorher von Hand gestoppt. - Keine Auswirkungen;-(Also nach jeweils 2 Versuchen pro Adapter habe ich jetzt alle aktualisieren können. Aber ob ich mir das nochmal antun würde? Hoffe, irgend jemand
findet den Fehler oder einen praktikablen Workaraound.Ach ja, und noch ein Hinweis. Den Node-Red Adapter selber habe ich nicht geupdatet, den habe ich seit einiger Zeit die 4.0.0 ohne Probleme am Laufen.
Gruß
Reiner -
War mal wieder soweit. 7 Adapter standen zum update an und da morgen Feiertag ist... ;-)
Vlt können die Erfahrungen zur Fehlersuche beitragen. Jedenfalls hatte ich bei allen 7 Adaptern nachvollziebar das gleiche Fehlerbild. Bin wie folgt vorgegangen:
- temp Dateien gelöscht. das es ohne nicht geht, habe ich letztens schon erfahren müssen.
iobroker@iobroker:~$ for i in $(find /opt/iobroker/node_modules -type d -iname ".*-????????" ! -iname ".local-chromium"); do rm -rf ${i%%/}; done- Adapter Update z.B.:
iobroker@iobroker:~$ iob upgrade pushover@3.0.3 --debugUnd jetzt wird es interessant. Fehler:
npm ERR! code ENOTEMPTY npm ERR! syscall rename npm ERR! path /opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src npm ERR! dest /opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src npm ERR! errno -39 npm ERR! ENOTEMPTY: directory not empty, rename '/opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src' -> '/opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src'Und zwar bei allen 7 Adaptern IMMER das gleiche Verzeichnis.
-
Nochmal gelöscht. siehe 1.
-
Nochmal update. siehe 2.
Und beim 2.ten mal lief das Update jedesmal ordentlich durch! Und das nachvollziehbar bei jedem der 7 Adapter.
Was hab ich sonst noch getestet?
Da das angemeckerte Verzeichnis ein Node-red Verzeichnis ist, habe ich den NR-Adapter mal vor dem Update gestoppt. Hatte keine Auswirkungen.Den einzigen Unterschied, den ich zwischen den jeweils ersten Update-Versuch und dem nachfolgenden erfolgreichen gesehen habe, war die Tatsache, dass der Adapter nach dem ersten Versuch natürlich gestoppt war.
Also habe ich testweise beim nächsten Adapter diesen vorher von Hand gestoppt. - Keine Auswirkungen;-(Also nach jeweils 2 Versuchen pro Adapter habe ich jetzt alle aktualisieren können. Aber ob ich mir das nochmal antun würde? Hoffe, irgend jemand
findet den Fehler oder einen praktikablen Workaraound.Ach ja, und noch ein Hinweis. Den Node-Red Adapter selber habe ich nicht geupdatet, den habe ich seit einiger Zeit die 4.0.0 ohne Probleme am Laufen.
Gruß
Reiner -
War mal wieder soweit. 7 Adapter standen zum update an und da morgen Feiertag ist... ;-)
Vlt können die Erfahrungen zur Fehlersuche beitragen. Jedenfalls hatte ich bei allen 7 Adaptern nachvollziebar das gleiche Fehlerbild. Bin wie folgt vorgegangen:
- temp Dateien gelöscht. das es ohne nicht geht, habe ich letztens schon erfahren müssen.
iobroker@iobroker:~$ for i in $(find /opt/iobroker/node_modules -type d -iname ".*-????????" ! -iname ".local-chromium"); do rm -rf ${i%%/}; done- Adapter Update z.B.:
iobroker@iobroker:~$ iob upgrade pushover@3.0.3 --debugUnd jetzt wird es interessant. Fehler:
npm ERR! code ENOTEMPTY npm ERR! syscall rename npm ERR! path /opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src npm ERR! dest /opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src npm ERR! errno -39 npm ERR! ENOTEMPTY: directory not empty, rename '/opt/iobroker/node_modules/node-red-node-email/node_modules/encoding-japanese/src' -> '/opt/iobroker/node_modules/.node-red-node-email-1lk8B7Gi/node_modules/encoding-japanese/src'Und zwar bei allen 7 Adaptern IMMER das gleiche Verzeichnis.
-
Nochmal gelöscht. siehe 1.
-
Nochmal update. siehe 2.
Und beim 2.ten mal lief das Update jedesmal ordentlich durch! Und das nachvollziehbar bei jedem der 7 Adapter.
Was hab ich sonst noch getestet?
Da das angemeckerte Verzeichnis ein Node-red Verzeichnis ist, habe ich den NR-Adapter mal vor dem Update gestoppt. Hatte keine Auswirkungen.Den einzigen Unterschied, den ich zwischen den jeweils ersten Update-Versuch und dem nachfolgenden erfolgreichen gesehen habe, war die Tatsache, dass der Adapter nach dem ersten Versuch natürlich gestoppt war.
Also habe ich testweise beim nächsten Adapter diesen vorher von Hand gestoppt. - Keine Auswirkungen;-(Also nach jeweils 2 Versuchen pro Adapter habe ich jetzt alle aktualisieren können. Aber ob ich mir das nochmal antun würde? Hoffe, irgend jemand
findet den Fehler oder einen praktikablen Workaraound.Ach ja, und noch ein Hinweis. Den Node-Red Adapter selber habe ich nicht geupdatet, den habe ich seit einiger Zeit die 4.0.0 ohne Probleme am Laufen.
Gruß
Reiner@rewenode sagte in Untersuchung: code 25 fehlerlösung:
Jedenfalls hatte ich bei allen 7 Adaptern
Das ist klar. Ein Fehler irgendwo im Tree blockiert ein Update für alle Module.
-
@rewenode sagte in Untersuchung: code 25 fehlerlösung:
Jedenfalls hatte ich bei allen 7 Adaptern
Das ist klar. Ein Fehler irgendwo im Tree blockiert ein Update für alle Module.
@thomas-braun Worauf ich mir allerdings überhaupt keinen Reim machen kann, wieso war immer der erste Updateversuch erfolglos und der zweite erfolgreich? Wobei jeweils gleichermaßen vorab die Löschorgie stattgefunden hat?
Wenn die Löcherige nicht vorab durchgeführt wird, ist es scheinbar ein zufälliges Verzeichnis bei dem abgebrochen wird (Wahrscheinlich das erste temp-Verzeichnis wo das Update gerade drüber stolpert) -
@rewenode Wie gesagt - sind immer unterschiedliche Verzeichnisse - auch wenn es bei Dir das gleiche war - deshalb empfehle ich ja auch das ganze node_modules Verzeichnis neu aufzubauen.
-
@mickym Hab grad kein Testsystem und bin froh, das die Updates erstmal gelaufen sind.
Hat sonst noch jemand das Problem dauerhaft lösen können, indem er das nodes_modules Verzeichnis neu aufgebaut hat?Wenn man im Netz nach
npm err! code enotemptysucht findet man das Phänomen recht häufig. Da sind aber oft aus meinen Augen schon fragwürdige Installationsvorgänge mit root/sudo oder -g Flag oder sonstige hingepfuschte Installationen im Spiel.Wenn ich das richtig eingrenze hat das mit SEMVER und der package.json / package-lock-json zu tun.
-
@mickym Hab grad kein Testsystem und bin froh, das die Updates erstmal gelaufen sind.
Hat sonst noch jemand das Problem dauerhaft lösen können, indem er das nodes_modules Verzeichnis neu aufgebaut hat?@rewenode sagte in Untersuchung: code 25 fehlerlösung:
@mickym Hab grad kein Testsystem und bin froh, das die Updates erstmal gelaufen sind.
Hat sonst noch jemand das Problem dauerhaft lösen können, indem er das nodes_modules Verzeichnis neu aufgebaut hat?Ja ;) - Natürlich sollte man vorher eine Sicherung machen. Und ich hab den Thread ja unten verlinkt, wo es wunderbar geklappt hat. ;)
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@rewenode sagte in Untersuchung: code 25 fehlerlösung:
@mickym Hab grad kein Testsystem und bin froh, das die Updates erstmal gelaufen sind.
Hat sonst noch jemand das Problem dauerhaft lösen können, indem er das nodes_modules Verzeichnis neu aufgebaut hat?Ja ;) - Natürlich sollte man vorher eine Sicherung machen. Und ich hab den Thread ja unten verlinkt, wo es wunderbar geklappt hat. ;)
Meine Vermutung ist, das diese temporären Verzeichnisse durch scheiternde Versuche entstehen binäre node-red-Nodes zu bauen.
Die ganzen Verzeichnisse kommen überwiegend aus der node-red-Ecke. Der abbrev-Kram, der oft als erstes auftaucht:
echad@chet:/opt/iobroker $ npm ls abbrev iobroker.inst@3.0.0 /opt/iobroker └─┬ iobroker.node-red@4.0.0 └─┬ node-red@3.0.2 └─┬ nopt@5.0.0 └── abbrev@1.1.1Das würde auch erklären, warum manche wiederkehrend das Problem haben und andere nicht.
gyp kommt nicht zu Ende und die zum bauen verwendeten Verzeichnisse bleiben stehen. -
@mickym @Thomas-Braun
Mal ne ganz dumme Frage eines linux/npm Frischlings.
Hab mir grad mal mein aktuelles node-modules Verzeichnis angesehen.iobroker@iobroker:~/node_modules$ ls -l total 3000 drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 abab drwxr-xr-x 2 iobroker iobroker 4096 Okt 2 21:36 abbrev drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 abort-controller drwxr-xr-x 2 iobroker iobroker 4096 Okt 2 21:36 accepts drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acme-http-01-standalone drwxr-xr-x 4 iobroker iobroker 4096 Okt 2 21:36 acorn drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acorn-globals drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acorn-walk drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 addressparser drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 after //u.s.wDas Datum entspricht dem letzten gestrigen Updates egal wie tief ich in die Subverzeichnisse schaue.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Dazu würde auch passen, dass das Update (im Vergeleich zu früher) so quälend lang dauert.
Das eigentliche Erstellungsdatum wird bei mir im Container leider nicht gezeigt;-(iobroker@iobroker:~/node_modules$ stat node-red File: node-red Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 801h/2049d Inode: 12876888 Links: 5 Access: (0755/drwxr-xr-x) Uid: ( 1000/iobroker) Gid: ( 1000/iobroker) Access: 2022-10-02 21:35:28.934884921 +0200 Modify: 2022-10-02 21:36:28.133494430 +0200 Change: 2022-10-02 21:36:28.133494430 +0200 Birth: -Egal wo ich schaue Birth: ist immer -
-
@mickym @Thomas-Braun
Mal ne ganz dumme Frage eines linux/npm Frischlings.
Hab mir grad mal mein aktuelles node-modules Verzeichnis angesehen.iobroker@iobroker:~/node_modules$ ls -l total 3000 drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 abab drwxr-xr-x 2 iobroker iobroker 4096 Okt 2 21:36 abbrev drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 abort-controller drwxr-xr-x 2 iobroker iobroker 4096 Okt 2 21:36 accepts drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acme-http-01-standalone drwxr-xr-x 4 iobroker iobroker 4096 Okt 2 21:36 acorn drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acorn-globals drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 acorn-walk drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 addressparser drwxr-xr-x 3 iobroker iobroker 4096 Okt 2 21:36 after //u.s.wDas Datum entspricht dem letzten gestrigen Updates egal wie tief ich in die Subverzeichnisse schaue.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Dazu würde auch passen, dass das Update (im Vergeleich zu früher) so quälend lang dauert.
Das eigentliche Erstellungsdatum wird bei mir im Container leider nicht gezeigt;-(iobroker@iobroker:~/node_modules$ stat node-red File: node-red Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 801h/2049d Inode: 12876888 Links: 5 Access: (0755/drwxr-xr-x) Uid: ( 1000/iobroker) Gid: ( 1000/iobroker) Access: 2022-10-02 21:35:28.934884921 +0200 Modify: 2022-10-02 21:36:28.133494430 +0200 Change: 2022-10-02 21:36:28.133494430 +0200 Birth: -Egal wo ich schaue Birth: ist immer -
Du stehst eh im falschen Verzeichnis...
iobroker@iobroker:~/node_modules$Ist /home/iobroker/node_modules, also das home-Verzeichnis. Der iobroker wohnt aber in /opt/iobroker.
Es sei denn, der node-red-Kram soll da wirklich hin, kann ich mir aber nicht vorstellen.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.
-
Du stehst eh im falschen Verzeichnis...
iobroker@iobroker:~/node_modules$Ist /home/iobroker/node_modules, also das home-Verzeichnis. Der iobroker wohnt aber in /opt/iobroker.
Es sei denn, der node-red-Kram soll da wirklich hin, kann ich mir aber nicht vorstellen.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.
@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
Du stehst eh im falschen Verzeichnis...
Nop, zumindest nicht im Dockercontainer. Auszug aus dem Dockerfile:
# Install ioBroker RUN curl -sL https://iobroker.net/install.sh | bash - \ && mkdir -p /opt/scripts/.docker_config/ \ && echo "starting" > /opt/scripts/.docker_config/.healthcheck \ && echo "${VERSION}" > /opt/scripts/.docker_config/.thisisdocker \ && echo $(hostname) > /opt/.firstrun \ # Deleting UUID from build && iobroker unsetup -y \ # Backup initial ioBroker and userscript folder && tar -cf /opt/initial_iobroker.tar /opt/iobroker \ && tar -cf /opt/initial_userscripts.tar /opt/userscripts \ # Setting up iobroker-user (shell, home dir and rights) && chsh -s /bin/bash iobroker \ && usermod --home /opt/iobroker iobroker \ && usermod -u 1000 iobroker \ && groupmod -g 1000 iobroker \ && chown root:iobroker /usr/sbin/gosu \ && chmod +s /usr/sbin/gosu \ # Clean up installation cache && apt-get autoclean -y \ && apt-get autoremove \ && apt-get clean \ && rm -rf /tmp/* /var/tmp/* \ && rm -rf /root/.cache/* /root/.npm/* \ && rm -rf /var/lib/apt/lists/*Zeile 14
reiner@rock64:~$ docker exec -u 1000:1000 -ti iobroker /bin/bash iobroker@iobroker:~$ pwd /opt/iobroker iobroker@iobroker:~$ -
Du stehst eh im falschen Verzeichnis...
iobroker@iobroker:~/node_modules$Ist /home/iobroker/node_modules, also das home-Verzeichnis. Der iobroker wohnt aber in /opt/iobroker.
Es sei denn, der node-red-Kram soll da wirklich hin, kann ich mir aber nicht vorstellen.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.
@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.
Ja, deshalb frage ich mich, was es bringen kann, das node-modules Verzeichnis neu aufzubauen.
-
@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
Du stehst eh im falschen Verzeichnis...
Nop, zumindest nicht im Dockercontainer. Auszug aus dem Dockerfile:
# Install ioBroker RUN curl -sL https://iobroker.net/install.sh | bash - \ && mkdir -p /opt/scripts/.docker_config/ \ && echo "starting" > /opt/scripts/.docker_config/.healthcheck \ && echo "${VERSION}" > /opt/scripts/.docker_config/.thisisdocker \ && echo $(hostname) > /opt/.firstrun \ # Deleting UUID from build && iobroker unsetup -y \ # Backup initial ioBroker and userscript folder && tar -cf /opt/initial_iobroker.tar /opt/iobroker \ && tar -cf /opt/initial_userscripts.tar /opt/userscripts \ # Setting up iobroker-user (shell, home dir and rights) && chsh -s /bin/bash iobroker \ && usermod --home /opt/iobroker iobroker \ && usermod -u 1000 iobroker \ && groupmod -g 1000 iobroker \ && chown root:iobroker /usr/sbin/gosu \ && chmod +s /usr/sbin/gosu \ # Clean up installation cache && apt-get autoclean -y \ && apt-get autoremove \ && apt-get clean \ && rm -rf /tmp/* /var/tmp/* \ && rm -rf /root/.cache/* /root/.npm/* \ && rm -rf /var/lib/apt/lists/*Zeile 14
reiner@rock64:~$ docker exec -u 1000:1000 -ti iobroker /bin/bash iobroker@iobroker:~$ pwd /opt/iobroker iobroker@iobroker:~$Ich hasse diese Docker-Scheisse
-
@Homoran Also bei mir war das Ganze auch reproduzierbar.
Dank dem Befehl unterhttps://forum.iobroker.net/topic/57337/fehler-25-bei-adapter-install-update-mit-npm8/2
konnte ich alle Adapter upgraden, außer NodeRED. Da muss ich mal noch sehen, ob ich noch alte Verzeichnisse finde.
Allerdings zeigt es mir auf der Admin-Oberfläche immer noch an, dass Updates verfügbar wären. Bei der Suche werden dann allerdings keine gelistet:
Zudem kann ein Script wegen fehlender Berechtigung nicht gelöscht werden:
Viele Grüße
-
@Homoran Also bei mir war das Ganze auch reproduzierbar.
Dank dem Befehl unterhttps://forum.iobroker.net/topic/57337/fehler-25-bei-adapter-install-update-mit-npm8/2
konnte ich alle Adapter upgraden, außer NodeRED. Da muss ich mal noch sehen, ob ich noch alte Verzeichnisse finde.
Allerdings zeigt es mir auf der Admin-Oberfläche immer noch an, dass Updates verfügbar wären. Bei der Suche werden dann allerdings keine gelistet:
Zudem kann ein Script wegen fehlender Berechtigung nicht gelöscht werden:
Viele Grüße
-
@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:
iobroker updatesagt? Was in GUIs steht ist oft nicht wahr.
Passt schon, habe das natürlich mit iobroker update gecheckt, wollte das nur einfach melden, weil im Posting stand, ob es bei uns reproduzierbar ist.
GUI ist klar..iobroker update Used repository: stable Adapter "admin" : 6.2.22 , installed 6.2.22 Adapter "backitup" : 2.4.12 , installed 2.4.12 Adapter "discovery" : 3.0.5 , installed 3.0.5 Adapter "influxdb" : 3.1.8 , installed 3.1.8 Adapter "javascript" : 6.0.3 , installed 6.0.3 Controller "js-controller": 4.0.23 , installed 4.0.23 Adapter "loxone" : 3.0.0 , installed 3.0.0 Adapter "modbus" : 5.0.5 , installed 5.0.5 Adapter "mqtt" : 4.0.7 , installed 4.0.7 Adapter "node-red" : 4.0.0 , installed 4.0.0 Adapter "proxmox" : 1.3.4 , installed 1.3.4 Adapter "shelly" : 6.0.0 , installed 6.0.0 Adapter "simple-api" : 2.7.0 , installed 2.7.0 Adapter "socketio" : 4.2.0 , installed 4.2.0 Adapter "viessmannapi" : 2.0.9 , installed 2.0.9 Adapter "web" : 4.3.0 , installed 4.3.0 Adapter "ws" : 1.3.0 , installed 1.3.0Eher störend ist für mich der Fehler beim Löschen des Skripts.
Node ist übrigens v16.15.1
und
npm ist 8.11.0
793
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge