ds-mod und debug.cfg

TheChaos

Mitglied
Mitglied seit
23 Apr 2004
Beiträge
479
Punkte für Reaktionen
0
Punkte
0
Hi,

ich habs gestern endlich geschafft mir ein eigenens Firmware-Image zu erstellen. Habe das gestern für eine FB 5010 alles nach Anleitung gemacht und am Ende Firmware-Version 23.04.15ds-0.2.9 raus bekommen. Ich will eigentlich die ds-mod Features garnicht, ich hab nur eine einfache Möglichkeit gesucht, ein eigens compiliertes Prog in die Box dauerhaft zu bekommen. Das hat auch wunderbar geklappt.

Das ds-mod war auch anfänglich über das Webinterface der Fritz.Box verlinkt und das zeigt ja auf http://fritz.box:81 . Allerdings als ich die debug.cfg auf der Box erstellte und meine benötigten Sachen eintrug war das ds-mod von nun an nicht mehr erreichbar. Lösche ich die debug.cfg wieder, läuft das ds-mod! Sehr merkwürdig, wie ich finde, da ich hier gelesen habe, dass das ds-mod eigentlich nix mit der debug.cfg zu tun hat.

Vielleicht kann mir ja jemand den Zusammenhang näherbringen!

Danke!
 
Wie sieht denn deine debug.cfg aus? Sie sollte kein exit oder eine Endlosschleife enthalten, weil dann wird der ds-mod danach nicht mehr gestartet.

Mfg,
danisahne
 
Kann es sein, dass du was in die debug.cfg geschrieben hast, dass die Ausführung des dsmod verhindert?

MfG Oliver
 
olistudent schrieb:
Kann es sein, dass du was in die debug.cfg geschrieben hast, dass die Ausführung des dsmod verhindert?

MfG Oliver

ja nette Hypothese ;) dachte ich mir ja auch schon, wobei dagegen sprach, dass es ja heisst, dass die debug.cfg unabhängig vom ds-mod (und andersrum) ist.

die debug.cfg sieht so aus
Code:
sleep 15
echo "CMD=\"dbclient argument1 argument2\"" > /var/flash/dbClientCfg
studnetLogin.sh

kurze Erklärung: dbclient ist ein präparierter dropbear ssh client, der mir eine dauerhafte Verbindung zu einem Anmeldeserver herstellt, sonst kommt man hier nicht ins Uni-Netz. das Shell-Skript läuft nun in einer Endlosschleife um abgebrochene Verbindungen wieder aufzunehmen. Und da könnte jetzt der Fehler liegen: da es unendlich läuft wird die debug.cfg nicht abgearbeitet. Wusste nicht, dass sich das auf das mod auswirkt
Ein "studnetLogin.sh &" sollte doch dann reichen oder?

Danke schonmal!
 
Genau. Wenn du das Skript im Hintergrund startest, so dass die Startdateien weiterverarbeitet werden, dann sollte das klappen.
Code:
(sleep 15;echo "CMD=\"dbclient argument1 argument2\"" > /var/flash/dbClientCfg;studnetLogin.sh)&
Eventuell auch so. Musst du mal probieren.

MfG Oliver
 
vielleicht könntet ihr mir nochmal kurz helfen:
wenn ich mein dbclient in den hintergrund starten will, klappt mein login leider nicht. da dachte ich mir, screen ist doch DIE alternative. hab ich eben nochmal ein neues Firmware erstellt um screen auf der box zu haben. Wenn ich aber "screen" eingebe bekomme ich nur den error
Code:
Cannot access //.screen: No such file or directory
hab schon versucht unter /var/tmp ein File .screen anzulegen, aber es läuft einfach nich :(

biiittteee hilfe ;)
 
muss ich hierfür echt noch ein neues Thema eröffnen? Irgendjemand muss doch schonmal screen benutzt haben, vor allem danisahne vielleicht?! :)

daaaanke!!
 
Ich hab das Screen-Package testweise in meine Firmware gebaut. Und bei der Eingabe von "screen" startet alles wie es soll.

Mfg Oliver
 
Das ist richtig. Im ds-mod läuft das Screen-Package tadellos.
Gruß Niko
 
olistudent schrieb:
Ich hab das Screen-Package testweise in meine Firmware gebaut. Und bei der Eingabe von "screen" startet alles wie es soll.

Mfg Oliver

danke dir vielmals. das verwundert mich jetzt umso mehr :( dann kann es doch fast nur an meiner 5010 liegen oder? na gut ich bastel dann mal weiter und meld mich bestimmt nochmal ;(
 
Ich hab jetzt keine Idee wo das herkommen könnte. Es gibt einmal das Wrapper-Skript "screen" und dann das eigentliche Binary "screen.bin". Schau mal von wo der Fehler kommt.

MfG Oliver
 
das kommt bei beidem, egal was ich starte. wenn dann müsste ich aber nur "screen" starten, weil das ja Variablen setzt, oder?! aber der fehler ist bei beiden da.
mir kam gerade noch die idee, dass es noch daran liegt, dass wie oben beschrieben, ds-mod aufgrund der "Ungereimtheiten" in der debug.cfg nicht richtig lädt. ich hatte heut noch keine Zeit das zu testen. werde ich spätestens am Montag machen können. ich meld mich nochmal! ;)
 
sooo, leider wie zu erwarten war, keine Verbesserung. Das dsmod Webinterface läuft und nix blockiert mehr den Ablauf der debug.cfg

Aber weiterhin, wenn ich mich per Telnet einlogge und auf der Console "screen" eingebe kommt
Code:
Cannot access //.screen: No such file or directory
Am Wrapperscript liegts nicht, da kann er meines Wissens nach alles finden. Also irgendwie geht die screen.bin-Anwendung nicht. Liegts an meinem Box-Typ oder hätte ich noch was ins Kernel compilieren müssen? Ist echt doof leider so und vor allem unverständlich.

Vielleicht habt ihr ja ne Idee!
Danke!
 
In dem Wrapper Skript werden aber ein paar wichtige Umgebungsvariablen gesetzt. Geht es bei dir auch mit Wrapper Skript nicht?
 
vielleicht hab ich es ungeschickt formuliert. ich habe die Einträge
Code:
[ -f "$TERMINFO"/*/"$TERM" ] || export TERM=xterm
touch /var/run/utmp
überprüft. Wenn ich mit Putty eingeloggt bin, sehe ich das passende terminfo. auch /var/run/utmp existiert.
Starten tu ich das ganze natürlich über /usr/bin/screen und der besagte Fehler kommt!
 
Die TERMINFO Variable auch? Das terminfo Verzeichnis ist auch dabei?
 
also
Code:
export TERMINFO=/mod/pkg/screen/usr/share/terminfo
setzt doch den Wert von terminfo eh, das kann ich ja auch schlecht überprüfen, da es ja nur für die laufende Shell gilt
und
Code:
TERM='vt102'
ist ja auch korrekt. demzufolge existiert auch /mod/pkg/screen/usr/share/terminfo/v/vt102
und wie gesagt /var/run/utmp existiert auch.
also weiss ich persönlich auch nicht mehr worans liegen soll :(
 
TheChaos schrieb:
demzufolge existiert auch /mod/pkg/screen/usr/share/terminfo/v/vt102
Existiert es auch wirklich? Der Folgerung "demzufolge" kann ich irgendwie nicht ganz folgen.

Mfg,
danisahne
 
naja, mit demzufolge war gemeint, wenn das Termn so heisst muss auch die Datei so heissen und sie existiert
Code:
~ # ls -l /mod/pkg/screen/usr/share/terminfo/v/vt102
-rw-r--r--    1 root     root         1141 Jan  4  2005 /mod/pkg/screen/usr/share/terminfo/v/vt102
ein "cat" bringt mir cryptisches Output.

Kannst du dir wenigstens vorstellen, was die Fehlermeldung mit "//.screen" meint? Ist das irgendeine Settingsdatei die er sucht oder wie kann man das verstehen? Es ist echt zum verzweifeln ;(
 
Was es mit .screen auf sich hat

TheChaos schrieb:
Kannst du dir wenigstens vorstellen, was die Fehlermeldung mit "//.screen" meint? Ist das irgendeine Settingsdatei die er sucht oder wie kann man das verstehen?

Jein, keine Datei, sondern ein Verzeichnis. Es ist das sog. "socket directory" (vgl. Screen-Manual), welches standardmäßig im Home-Verzeichnis des Benutzers angelegt wird. Da der Benutzer normalerweise root und sein Home-Verzeichnis üblicherweise / ist, versucht screen, das Verzeichnis dort anzulegen, was scheitern muß - es handelt sich schließlich um ein Read-Only-Dateisystem.

Lösung: Sofern die Umgebungsvariable SCREENDIR existiert, verwendet screen das dort angegebene Verzeichnis als socket directory. Man muß es auch nicht manuell anlegen, Screen erledigt das. Automatisch gelöscht wird es nach Ende des Screen-Prozesses allerdings nicht, ist aber auch egal. Also in die debug.cfg oder das Startskript von Screen Folgendes eintragen (oder eben an der Kommandozeile eingeben):
Code:
export SCREENDIR=/var/tmp/.screen
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
246,274
Beiträge
2,249,293
Mitglieder
373,863
Neuestes Mitglied
RuthBeatty
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.