Nochmal @plex.web: Ja, es wird nach Möglichkeit keiner vergessen. Ich bin Freiberufler und leite ab und zu ein paar Software-Großprojekte. Das Programmieren mache ich seit Jahren nur noch zum Spaß, damit ich es nicht ganz verlerne. Und im Gegensatz zum ds26 bringt mir die Arbeit als Projektmanager und Coach sogar das Geld, das ich zum Leben brauche. Ihr dürft mich gern alle engagieren oder empfehlen, meine Webseite steht ja im Profil. [Werbung Ende] Wenn ich dann so reich bin, daß ich nicht mehr arbeiten muß, mache ich nur noch DS-Mod... ;-)
x
@Niko: Ob der Energiemoni laufen soll oder nicht, wissen wir nicht, so blöd sich das anhört. Wir kennen das ungefähre Umfeld (Stichwort Soft-Float), in dem wir uns bewegen müssen, um herauszufinden, warum er in manchen Fällen geht, in anderen nicht, aber 100%ig wissen wir es noch nicht. Das war aber kein Showstopper fürs Release.
x
@Bodega: Der
ctlmgr verwendet sicher nicht mehr Speicher als früher, denn wir verändern ihn ja nicht. Es kann eher sein, daß das
top-Applet der BusyBox 1.5.1 anders rechnet als das vorherige. Wenn Du genau sehen willst, was der Prozeß sich so alles in den Speicher schlürft, kannst Du Dir die Ausgabe von
Code:
cat /proc/$(pidof ctlmgr)/maps)
anschauen. Nachteil dabei ist nur, daß Du sie auch interpretieren können mußt und zu beachten ist, daß Shared Libs ja i.d.R. nicht nur von einem Prozeß verwendet werden.
xDaß der Telnet-Client beim
exit hängen bleibt, ist ein
uraltes Phänomen, das auch nur auf der ersten Konsole
/dev/pts/0 vorkommt. Mach mal eine zweite Telnet-Konsole auf und setze dort
exit ab. Es wird funktionieren. Wird wohl irgendwas in der Busybox sein.
x
schrimp schrieb:
Ich möchte gerne Dateien fest im /var-Bereich anlegen, damit ich sie später bei Bedarf noch verändern kann. Kann ich dazu einfach in /ds26-xx/root/ einen var-ordner anlegen oder muss ich das anders handhaben?
Da
/var eine RAM-Disk ist, würde es nichts bringen, das so zu machen. Was nach
/var soll, muß dynamisch erzeugt werden. AVM legt z.B. ins Root-Verzeichnis ein
var.tar, welches beim Boot-Vorgang nach
/var entpackt wird, desweiteren werden diverse weitere Dateien angelegt. Am einfachsten geht das aus
/var/flash/debug.cfg oder
/tmp/flash/rc.custom heraus mittels sog. Hier-Dokumente, also mit
Code:
cat << 'EOF' > /var/myfile
# Hierher alles, was in die Datei soll
EOF
# Falls notwendig, noch dies:
chmod +x /var/myfile
Falls die Datenmengen, die Du erzeugst, umfangreicher sind und nichts ins TFFS passen, wo
debug.cfg bzw.
rc.custom gespeichert werden, dann lieber nachlasen mit wget oder über einen externen Mount.
x
morph027 schrieb:
Um PPPD zu kompilieren, muss lediglich libpcap mit ausgewählt werden (Shared Libs), müsste meinem Verständnis nach also nur mit in die config.in des Paketes aufgenommen werden.
Ja, das Auswählen der Lib hilft erst mal, auch wenn es die Ursache nicht beseitigt. Hintergrund:
PPPD braucht die Library nicht, wie man mit
ldd leicht feststellen kann. Dafür braucht er aber Header-Files der
libpcap, und das merkt man nur, wenn man kein anderes Paket mit
libpcap ausgewählt hat. Wir testen hier -zig Pakete, die nicht alle von uns sind, und da kann man schon rein rechnerisch nicht alle Kombinationen durchprobieren. Dafür gibt's ja Euch. ;-) Oliver behebt das Problem (bzw. hat schon, glaube ich). Patch kommt in ein, zwei Tagen, wenn wir noch ein paar andere Sachen gefixt haben.
x
@Willi72 und alle anderen mit der Fehlermeldung
"kernel image too big": Es ist altbekannt - deswegen muß es nicht jeder Einsteiger wissen und wir wiederholen es ab und zu - daß
Menuconfig, das ja nicht wir programmiert haben, sondern aus dem Buildroot-Projekt übernommen wurde und dort wiederum aus dem Linux-Kernel-Paket (Stichwort Kernel-Konfiguration), keine Referenzzählung bei Abhängigkeiten beherrscht, d.h. daß es zwar abhängige Teile (Bibliotheken, Module) automatisch auswählen, aber hinterher nicht feststellen kann, ob sie wieder abgewählt werden müssen, da ja andere Module die gleiche Abhängigkeit haben könnten oder der Benutzer manuell eine bestimmte Bibliothek ausgewählt haben könnte. Daher ist es wirklich wichtig, nach dem Abwählen von vorher in der Konfiguration gespeicherten Paketen unter "Advanced options" -> "Shared libraries" bzw. "Kernel modules" nachzuprüfen, ob dort nicht noch etwas angekreuzt ist, das man weglassen könnte. Dabei sind fest benötigte Teile mit "---" markiert, weil sie aufgrund Abhängigkeiten nicht deselektiert werden können. Die mit "[x]" kann man dagegen entfernen, sie werden i.d.R. nicht gebraucht, wenn man als Benutzer nicht sicher weiß, daß man sie haben möchte. Ich werde in Beitrag 1 des Themas ein FAQ machen.
x
morph027 schrieb:
Dafür hats mir meine Eumex 300 jetzt abgeschossen....blinkende Power-LED, make recover RECOVER=ds sagt mir
Code:
flashing mtd1 can't open data connection
Recover muß man u.U. öfter versuchen, das geht nur unmittelbar nach dem Einstecken der Box. Im Zweifel auch mal das Recover-Werkzeug vom AVM-FTP-Server (
recover*.exe) verwenden. Davon abgesehen, bringt die Fehlermeldung "abgeschossen" wenig. Was hast Du gemacht, welche Pakete sind ausgewählt (
.config als Dateianhang posten)? Was hat nicht geklappt? Hast Du etwas in der
debug.cfg?
xZu den Postings im Stil "ich traue mich nicht, das fertige Image zu flashen, weil ich evtl. er Erste bin, der es für diesen Hardware-Typ versucht oder die Box hängen bleiben könnte" ist zu sagen: Versucht es, Leute, sonst werdet Ihr nie wissen, ob es geht. Wir haben hier leider keine 20 Boxen herumstehen zum Testen. Normalerweise sollte es gehen, und falls nicht, besorgt Euch vor dem Flashen ein Recover-Tool (s.o.) für Eure Box, damit kriegt Ihr sie in jedem Fall wieder zum Laufen.
