Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Thomas Braun]

@Bastian-B Ich würde den nvm-Kram rauskicken, oder musst du 'on the fly' node-Versionen wechseln?
(Vermutlich nicht, sonst würdest du nicht fragen, was da bei dir falsch läuft...)

Ich habe bei mir lediglich für jeden Zweig ein eigenes Repo in der Paketverwaltung und kann da bei Bedarf ähnlich schnell wechseln. Meist tu ich das aber auch gar nicht, sondern bleibe auf dem Zweig, der am besten funktioniert.

Jedenfalls schaut das so aus:

OK:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:2 http://archive.raspberrypi.org/debian buster InRelease
OK:3 https://deb.nodesource.com/node_10.x buster InRelease
OK:4 https://deb.nodesource.com/node_12.x buster InRelease
OK:5 https://deb.nodesource.com/node_14.x buster InRelease 

[Bastian B.]

Ich habe NVM bereits entfernt. Ich habe alles entfernt was ich finden konnte. Aber die Installation funktioniert nicht.

1. Ich habe mit "apt-get purge" alles entfernt und die Ordner entfernt.
2. "which nodejs && nodejs -v && which node && node -v && which npm && npm -v && apt policy nodejs" liefert nichts mehr. Ich gehe davon aus dass alles entfernt ist.
3. "curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -" und "sudo apt-get install -y nodejs"

Ich bekomme auch eine Erfolgsmeldung, aber node -v liefert nichts...

Aber nodejs -v liefert v0.10.29 Das ist doch eine uralt-Version, oder?!

[AlCalzone]

@paul53 sagte in node.js-Installation lokalisieren und entfernen:

Nachdem node.js eine Javascript-Anwendung compiliert und gestartet hat, beendet es sich selbst.

Das stimmt nicht. Die Anzeige in htop zeigt nur den "schönen" Prozessnamen (io.*), den ioBroker setzt.

top z.B. lässt erkennen, dass es immer noch node ist.

---

@Thomas-Braun sagte in node.js-Installation lokalisieren und entfernen:

Ich habe bei mir lediglich für jeden Zweig ein eigenes Repo in der Paketverwaltung und kann da bei Bedarf ähnlich schnell wechseln.

Wie machst du das?

[Thomas Braun]

@AlCalzone sagte in node.js-Installation lokalisieren und entfernen:

@Thomas-Braun sagte in node.js-Installation lokalisieren und entfernen:

Ich habe bei mir lediglich für jeden Zweig ein eigenes Repo in der Paketverwaltung und kann da bei Bedarf ähnlich schnell wechseln.

Wie machst du das?

Pro Zweig halt ein Repo und dann per apt gezielt die Version installieren:

pi@raspberrypi:~$ apt policy nodejs
nodejs:
  Installiert:           14.5.0-1nodesource1
  Installationskandidat: 14.5.0-1nodesource1
  Versionstabelle:
 *** 14.5.0-1nodesource1 500
        500 https://deb.nodesource.com/node_14.x buster/main armhf Packages
        100 /var/lib/dpkg/status
     12.18.2-1nodesource1 500
        500 https://deb.nodesource.com/node_12.x buster/main armhf Packages
     10.21.0-1nodesource1 500
        500 https://deb.nodesource.com/node_10.x buster/main armhf Packages
     10.21.0~dfsg-1~deb10u1+rpi1 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
pi@raspberrypi:~$ apt install nodejs=gewuenschteversion

Feintuning dann ggf. per Pinning. Ist aber meist nicht erforderlich. Ich bin gerne 'on the edge' unterwegs.
Zugegeben, für Zeitreisende, die Vorversionen testen müssen ist das nicht geeignet. Aber den jeweiligen Zweig kann man schnell wechseln.

[paul53]

@AlCalzone sagte:

top z.B. lässt erkennen, dass es immer noch node ist.

Das ist aber erst bei neuen Versionen so. Auf mein RaspPi zeigt top:

top - 21:40:09 up 44 days, 21:21,  1 user,  load average: 0,02, 0,03, 0,00
Tasks: 124 total,   1 running, 123 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,9 us,  0,2 sy,  0,0 ni, 98,9 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:    945516 total,   597732 used,   347784 free,   129232 buffers
KiB Swap:        0 total,        0 used,        0 free.   151152 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  606 root      20   0  174652  92300  20860 S   1,0  9,8 794:46.22 iobroker.js-con
  791 root      20   0  165324  68720  20316 S   0,7  7,3 650:45.66 io.javascript.0
  785 root      20   0  142832  59512  20292 S   1,0  6,3 531:31.92 io.admin.0
  843 root      20   0  139464  55440  20420 S   0,0  5,9  64:04.86 io.web.0
  833 root      20   0  126300  44580  20256 S   0,7  4,7 331:08.06 io.history.0
  801 root      20   0  135220  43524  20252 S   0,0  4,6 182:43.34 io.hm-rpc.0
  815 root      20   0  123512  40764  20920 S   0,0  4,3  36:52.44 io.email.0
  449 hmcon     20   0   17148  10516   3592 S   0,0  1,1   9:58.36 rfd

[Thomas Braun]

@Bastian-B Bitte Konsolenausgaben nicht als Screenshot, sondern als Text in CodeTags hier rein. Sieht dann so aus:

apt policy nodejs
uname -a
lsb_release -a

Ausgaben komplett posten.
Ich wette auf ein Debian8 / Jessie mit 32bit-Kernel.
Das kannste schon mal platt machen und durch ein 64bit Buster ersetzen. Das Pferd ist schon 2 Jahre tot, Zeit zum absteigen.

[Bastian B.]

@Thomas-Braun: Ich komme auf die Kiste im Moment leider nur via VNC drauf. Da kann ich nur Screenshots machen.

Ja, ist ein 32-bit Jessie, genauer gesagt ein Raspian x86. :confounded:
Platt machen ist nicht, Da laufen über die Jahre so viele Dinge drauf. Jemand eine alternative Idee? Könnte man node.js in 32-bit kompilieren?

[Thomas Braun]

@Bastian-B Vielleicht mal rechtzeitig update -Strategien zurechtlegen? Gerade debian wird ja nicht urplötzlich und ohne Vorlauf abgekündigt. Jessie vor zwei Jahren generell und vor wenigen Tagen ist die gute dann auch sogar aus LTS gefallen (nach 5 Jahren seit Erstrelease). Wirklich mehr als überfällig da abzusatteln.

Und Server werden auch nicht per VNC administriert. SSH ist dein Freund.

[Bastian B.]

Was ist denn das eigentliche Problem mit Jessie? Tatsächlich der 32-bit Kernel?

[Thomas Braun]

@Bastian-B Die 32bit Architektur ist ja auch schon seit Jahren obsolet. Die wird nur noch von superexotischen Distributionen überhaupt gepflegt. Und das dann auch nur mit Ach und Krach, weil das immer schwieriger wird zu maintainen.
Ein Wechsel auf einen 64bit -Kernel ist auch nur was für Gurus (oder Masochisten) Geht unter Umständen, ist aber schwarze Magie. Kurz: Datensicherung und flugs auf was aktuelles wechseln.
Das Problem mit Jessie ist: Sie ist tot. Sogar so mausetot,dass nicht mal mehr das allernotwendigste mehr für Jessie gebaut wird.

[Bastian B.]

@Thomas-Braun

ok, so einfach geht das allerdings nicht. Die Installation hat einige Dienste usw. im Bauch, da habe ich leider dem Überblick verloren. Das Ganze lief ursprünglich mal auf einem Raspi, mittlerweile auf Raspian Desktop unter VMware. Hat also schon einen Architekturwechsel hinter sich. Ich möchte jetzt nur das Node.js auf Version 12 heben, mehr nicht. Einen Archtikturwechsel versuche ich zu vermeiden, das ist wirklich fies! Wenn also ein Upgrade von Jessie auf Stretch schon reichen würde, wäre das vielleicht ein Weg...

[Thomas Braun]

@Bastian-B nodesource (was am einfachsten zu handeln ist) baut aber seit node10 nicht mehr für 32bit. Musste selber ran.