Hallo,
kennt jemand eine Möglichkeit wie man den Editor nano anstatt vi uf dem Router installieren kann?
ein einfaches opkg install nano bricht mit dem Verweis auf zu wenig Spreicherplatz ab.
Danke und Gruß
vdb
1 „Gefällt mir“
Bei einem Router mit mehr Flash/RAM geht das… Da das knapp ist bei den günstigen Routern, basteln die GLUON-Entwickler nicht noch zusätzlich nano rein…
Arbeite Dich in VI ein, geht schon…
1 „Gefällt mir“
Allte Gluon (2015er) nehmen, da ist noch mehr Platz.
Oder besseren Router kaufen (wie Frank beschrieben hat)
oder rouer mi sshfs oder ähnlichem in ein Verzeichnis mounten und dann bequem mit deinem Lieblingstool vom Rechner aus die Dateien editieren … (oder kopieren und editieren …)
aber ob du nun sshfs - oder den genaueren syntax von scp oder ein bisserl vi lernst, kommt insgesamt aufs gleiche raus,
auf linuxrechnern gibts meist ein tool namens vimtutor … da lernt man so langsam wies geht, einfach mal im terminal starten (und sobald man weis wie man wieder rauskommt , und das es einen edit und einen command mode gibt ist eigtl. schon alles gut 
Falls es mit der Installation nicht klappt, hier vi für absolute Anfänger:
Nach dem Starten i drücken, damit man Text einfügen kann.
Dann kann man sich mit den Pfeiltasten durch den Text bewegen und einfach normal Sachen schreiben. (Wenn das mit den Pfeiltasten nicht geht ist mit der ssh-Verbindung höchstwahrscheinlich nicht in Ordnung. Putty und Linux-ssh sollten keine Probleme machen.)
Wenn man fertig ist: ESC-Taste drücken, und :wq eintippen und Enter drücken zum speichern und beenden. Um ohne zu speichern zu beenden: ESC-Taste drücken, :q! eintippen und Enter drücken.
1 „Gefällt mir“
Danke, Router ist ein TPLink WD841n, also sicher ein günstiger mit wenig Speicher.
Klar man kommt mit vi klar, ist halt nur nervig wenn man ihn nur selten benutzt.
Ok danke für die Aufklärung.
da ein df -h nun statt 91% statt vorher etwa 45% used auf rootfs anzeigt, hat der abgebrochenen installationsversuch nun noch irgendwo Speicherplatz belegt.
Filesystem Size Used Available Use% Mounted on
rootfs 384.0K 348.0K 36.0K 91% /
/dev/root 2.3M 2.3M 0 100% /rom
tmpfs 13.9M 356.0K 13.6M 2% /tmp
/dev/mtdblock3 384.0K 348.0K 36.0K 91% /overlay
overlayfs:/overlay 384.0K 348.0K 36.0K 91% /
tmpfs 512.0K 0 512.0K 0% /dev
Weiß jemand wie man den wieder frei bekommt, oder ob man sich darum sorgen muss?
Firmware aktualisieren wäre sicher ein Weg oder?
Exakt, das sind die 3 wichtigen Tastenkombinationen.
Mittlerweile kann die powershell auch SSH.
Du kannst nano temporär im RAM installieren, musst aber dann noch die entsprechenden Umgebungsvariablen für Pfad und Libraries anpassen.
Die Anpassungen können aber auch persistent bspw. in der /etc/profile durchgeführt werden.
opkg -d ram install nano
export PATH=$PATH:/tmp/usr/bin/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/usr/lib/
export TERMINFO=/tmp/usr/share/terminfo
nano
Edit:
Das eignet sich generell dazu, weitere Pakete temporär zu installieren, falls man z.B. spontan mal tcpdump, iperf und Konsorten benötigt.
Nach einem Reboot ist dann wieder alles wie vorher.
5 „Gefällt mir“
Einfach in der site.mk beim Bauen in die Liste tun. Das braucht natürlich Platz aber nano ist jetzt auch nicht wirklich groß. Iperf passt dann aber nicht mehr rein.
Nano ist zwar recht klein (25 KB), die Dependencies libncurses (113 KB) und terminfo (6 KB) kommen jedoch auch noch dazu.
Wenn dann noch die Opkg-Metadaten aktualisiert werden (und dann ins Overlay-FS wandern), werden auch noch mal ein paar hundert KB unkomprimiert fällig.
Deshalb lieber temporär im RAM installieren, wenn man es nur für den Moment braucht.
2 „Gefällt mir“
…und insofern nenne ich das dann auch „updatefest“ 
1 „Gefällt mir“
Wenn es noch kleine unwichtige Pakete gibt zum Schlachten, dann die runterwerfen, das grosse drueberbuegeln, dass es wieder konsistent wird und dann runter werfen. Und dann die kleinen wieder drauf. Die grossen zuerst.
Alles was Du nachinstallierst landet in einem Overlay.
d.h. da wird keine Speicher „frei“, wenn Du etwas herauswirfst/löchst.
Da musst Du dann schon eine eigene Firmware neu bauen. (Was nicht kompliziert ist, man muss es nur eben tun.)
1 „Gefällt mir“
Args…also im df alles schoen, aber das reflektiert nicht den externen Verschnitt des Containers in dem das liegt, also malloc wie immer… die genaue Implementierung war mir in dem Moment aber auch wirklich nicht klar. Oops da muss ich in einem anderen Thread wohl noch mal nacharbeiten…
1 „Gefällt mir“
Ich weiss zwar was Du sagen willst, aber eins irritiert mich daran nach wie vor: es ist ja nicht so, dass es nicht funktioniert haette! Insofern habe ich mich etwas ablenken lassen.
Es ging darum, ein kaputtes Paket wieder glatt zu kriegen ohne Gefummel. Und das ist fuer sich ja schon mal ein Gewinn. Wenn man das durchziehen kann wie oben ohne gegen Schranken zu laufen und es nachher wieder passt, muesste allein der Erfolg Deiner These doch Hohn sprechen. Kann sein, dabei brutto auch noch wieder ein paar Byte verloren gehen, aber die Kiste ist wieder konsistent. Habe ich ja schon mal so gemacht. Voraussetzung war aber,man hat ein weiteres bereits nachinstalliertes Schlachtopfer.