ds-mod und debug.cfg

[TheChaos]

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!

 

[danisahne]

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

 

[olistudent]

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

MfG Oliver

 

[TheChaos]

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

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!

 

[olistudent]

Genau. Wenn du das Skript im Hintergrund startest, so dass die Startdateien weiterverarbeitet werden, dann sollte das klappen.

(sleep 15;echo "CMD=\"dbclient argument1 argument2\"" > /var/flash/dbClientCfg;studnetLogin.sh)&

Eventuell auch so. Musst du mal probieren.

MfG Oliver

 

[TheChaos]

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

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

 

[TheChaos]

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

daaaanke!!

 

[olistudent]

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

Mfg Oliver

 

[jesus.christ]

Das ist richtig. Im ds-mod läuft das Screen-Package tadellos.
Gruß Niko

 

[TheChaos]

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 ;(

 

[olistudent]

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

 

[TheChaos]

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!

 

[TheChaos]

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

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!

 

[danisahne]

In dem Wrapper Skript werden aber ein paar wichtige Umgebungsvariablen gesetzt. Geht es bei dir auch mit Wrapper Skript nicht?

 

[TheChaos]

vielleicht hab ich es ungeschickt formuliert. ich habe die Einträge

[ -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!

 

[danisahne]

Die TERMINFO Variable auch? Das terminfo Verzeichnis ist auch dabei?

 

[TheChaos]

also

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

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

 

[danisahne]

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

 

[TheChaos]

naja, mit demzufolge war gemeint, wenn das Termn so heisst muss auch die Datei so heissen und sie existiert

~ # 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 ;(

 

[kriegaex]

Was es mit .screen auf sich hat

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):

export SCREENDIR=/var/tmp/.screen