SOLVED willkürliche abstürzte der Adapter seit node 10 update
-
@Jan1 https://ark.intel.com/content/www/de/de/ark/products/75277/intel-xeon-processor-e5-2680-v2-25m-cache-2-80-ghz.html
-
@Halmand Habe mal den einen (von mindestens zwei) Fall mit Xeon herausgesucht:
https://forum.iobroker.net/topic/27676/instanzen-laufen-instabil-u-a-admin-yakha-gelöst/35Nachdem dann in der VM statt Xeon ein i5 emuliert wurde lief es
-
@Halmand ooops,
mit Xeon gab es hier schon mal massive Probleme
und was bietet die Virtualisierung als CPU an?
-
@Homoran ok das klint ja schon mal interesant debian und iobroker an sich macht nicht die Probleme die einzelnen adapter stürzen ab ab node 10 bzw 12 intersant bei node 8 gehts die Virtualisierung gibt sie als gleiche prozessoren weiter
info von iobroker
-
-
@Thomas-Braun ist nicht lange her bar tage das ich das mal gemacht habe aber ich mache es mal
server@debian-iobroker:~$ sudo apt update [sudo] password for server: Get:1 ftp://ftp.at.debian.org/debian stretch InRelease Ign:1 ftp://ftp.at.debian.org/debian stretch InRelease Hit:2 ftp://ftp.at.debian.org/debian stretch Release Hit:3 https://deb.nodesource.com/node_10.x stretch InRelease Get:5 https://cpkg.datto.com/datto-deb/public/stretch stretch InRelease [3,172 B ] Err:5 https://cpkg.datto.com/datto-deb/public/stretch stretch InRelease The following signatures couldn't be verified because the public key is not av ailable: NO_PUBKEY 370C85D709D26407 Reading package lists... Done W: GPG error: https://cpkg.datto.com/datto-deb/public/stretch stretch InRelease: The following signatures couldn't be verified because the public key is not ava ilable: NO_PUBKEY 370C85D709D26407 E: The repository 'https://cpkg.datto.com/datto-deb/public/stretch stretch InRel ease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disa bled by default. N: See apt-secure(8) manpage for repository creation and user configuration deta ils. server@debian-iobroker:~$ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libsqlite0 linux-headers-4.9.0-11-amd64 linux-headers-4.9.0-11-common python-libxml2 python-lzma python-pycurl python-rpm python-sqlite python-sqlitecachec python-urlgrabber Use 'sudo apt autoremove' to remove them. The following NEW packages will be installed: linux-headers-4.9.0-12-amd64 linux-headers-4.9.0-12-common linux-image-4.9.0-12-amd64 The following packages will be upgraded: linux-headers-amd64 linux-image-amd64 2 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 47.5 MB of archives. After this operation, 243 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 ftp://ftp.at.debian.org/debian stretch/main amd64 linux-headers-4.9.0-12-common all 4.9.210-1 [7,741 kB] Get:2 ftp://ftp.at.debian.org/debian stretch/main amd64 linux-headers-4.9.0-12-amd64 amd64 4.9.210-1 [450 kB] Get:3 ftp://ftp.at.debian.org/debian stretch/main amd64 linux-headers-amd64 amd64 4.9+80+deb9u10 [6,106 B] Get:4 ftp://ftp.at.debian.org/debian stretch/main amd64 linux-image-4.9.0-12-amd64 amd64 4.9.210-1 [39.3 MB] Get:5 ftp://ftp.at.debian.org/debian stretch/main amd64 linux-image-amd64 amd64 4.9+80+deb9u10 [7,158 B] Fetched 47.5 MB in 5s (8,631 kB/s) Reading changelogs... Done Selecting previously unselected package linux-headers-4.9.0-12-common. (Reading database ... 101058 files and directories currently installed.) Preparing to unpack .../linux-headers-4.9.0-12-common_4.9.210-1_all.deb ... Unpacking linux-headers-4.9.0-12-common (4.9.210-1) ... Selecting previously unselected package linux-headers-4.9.0-12-amd64. Preparing to unpack .../linux-headers-4.9.0-12-amd64_4.9.210-1_amd64.deb ... Unpacking linux-headers-4.9.0-12-amd64 (4.9.210-1) ... Preparing to unpack .../linux-headers-amd64_4.9+80+deb9u10_amd64.deb ... Unpacking linux-headers-amd64 (4.9+80+deb9u10) over (4.9+80+deb9u9) ... Selecting previously unselected package linux-image-4.9.0-12-amd64. Preparing to unpack .../linux-image-4.9.0-12-amd64_4.9.210-1_amd64.deb ... Unpacking linux-image-4.9.0-12-amd64 (4.9.210-1) ... Preparing to unpack .../linux-image-amd64_4.9+80+deb9u10_amd64.deb ... Unpacking linux-image-amd64 (4.9+80+deb9u10) over (4.9+80+deb9u4) ... Setting up linux-image-4.9.0-12-amd64 (4.9.210-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.9.0-6-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-4.9.0-6-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-4.9.0-12-amd64 I: /initrd.img is now a symlink to boot/initrd.img-4.9.0-12-amd64 /etc/kernel/postinst.d/dkms: find: ‘/var/lib/dkms/dattobd/0.10.13/build/configure-tests/feature-tests/build/’: No such file or directory /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.9.0-12-amd64 /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.9.0-12-amd64 Found initrd image: /boot/initrd.img-4.9.0-12-amd64 Found linux image: /boot/vmlinuz-4.9.0-6-amd64 Found initrd image: /boot/initrd.img-4.9.0-6-amd64 Found linux image: /boot/vmlinuz-4.9.0-3-amd64 Found initrd image: /boot/initrd.img-4.9.0-3-amd64 done Setting up linux-headers-4.9.0-12-common (4.9.210-1) ... Setting up linux-image-amd64 (4.9+80+deb9u10) ... Setting up linux-headers-4.9.0-12-amd64 (4.9.210-1) ... Setting up linux-headers-amd64 (4.9+80+deb9u10) ... server@debian-iobroker:~$ -
@Halmand Das überrascht mich jetzt etwas, nachdem der Fixer oben da so in's Schleudern geraten ist.
Auf jedenfall mal rebooten, da war ein Kernel-Update dabei. -
aber Danke erstmals für die mühe mein frankensteinsystem wieder zu laufen zu bekommen ich wer zu bett und übermorgen wieder weiter machen. Mysteriös ist das ein clean System auch nicht will irgendein kleinen oder großen fehler mache ich
-
@Halmand Habe mal den einen (von mindestens zwei) Fall mit Xeon herausgesucht:
https://forum.iobroker.net/topic/27676/instanzen-laufen-instabil-u-a-admin-yakha-gelöst/35Nachdem dann in der VM statt Xeon ein i5 emuliert wurde lief es
-
@Halmand
Was ist eigentlich der Kram von datto da? Mit dem unsignierten key. Das würde mich ja auch schon wieder mehr als stutzen lassen. Hast du den ioBroker auf 'nem root-Server laufen? -
@Thomas-Braun das mit datto sehe ich auch das erste mal bei dem befehl muss mal gucken wo das herkommt und nein die Maschine steht bei mir zuhause im serverschrank
-
@Homoran ich werd mal die Virtualisierung mal auf eine andere maschine instalieren und verschieben vielleicht geht es dann bin gespannt
-
das mit datto sehe ich auch das erste mal bei dem befehl muss mal gucken wo das herkommt
DAS würde ich an deiner Stelle auch machen...
-
@Thomas-Braun @Homoran so ich danke für eure Hilfe das problem mit den prozessoren war genau richtig!!! OB IObroker neue version oder node 10 bzw 12 macht anscheinend große Probleme auf die Xeon prozessoren ich habe nämlich jetzt die VM so gelassen wie sie ist hab ein 2ten hypervisor server auf 2 maschine (Intel J1900 cpu) und hab die VM einfach verschoben wie sie ist inklusive selben ip und co und siehe da problem sind weg!!! vielen vielen dank für den TIp vieleicht sollte man noch extra forum beitrag dazu erstellen um genaue lösung zu finden oder fixen
