Moin zusammen,
auf meiner Eumex hatte ich ein interessantes Problem/Phänomen:
Die Einstellungen, die ich im Telefonie-Bereich gemacht hatte (eigene Rufnummer, Telefone) waren nach jedem Neustart weg. Das hat mich, da ich den Part eher selten nutze (außer zum "Fritz-Faxen") nicht so sehr gestört, aber dann doch neugierig gemacht.
Folgenden fand ich heraus:
Beim Booten prüft das rc.S Skript, ob in den gerade erzeugten Nodes im Flash was drin ist, wenn nicht, werden die defaults geladen ("copy_telefonie_defaults fx_conf ${OEM} ${Country} ${OEM_DEFAULT_INDEX"). Dabei geht das Skript so vor, dass die Defaults per "cp" dorthin kopiert werden. Mit dem Resultat, dass die Specila-Devicces "verschwinden" und "normale" Dateien erstellt werden. Alle Änderungen gehen so natürlich verloren.
Beim Hochfahren sieht das dann so aus:
Das konnte ich nun umgehen, indem ich die Datei gelöscht habe, mit mknod das Device angelegt habe, mit "cat" die defaults hineingeschreiben habe (was ja eigentlich auch "richtiger" wäre als cp, oder?!?) und, siehe da, die Änderungen waren "resetfest".
Soweit, so schlecht. Meine Frage war: WARUM ?!?
Ich habe festgestellt, mit der originalen 04.33-er Firmware geht es mit "cp" beim 2.6-er nicht. Kann das jemand nachvollziehen??
Mit einer "originalen" Firmware geht es, es scheint also am "ds-mod Busybox cp" zu liegen???
Der ultimative Test (AVM-cp auf dem ds-mod) geht leider nicht, da der Befehl mit einem "Segmentation fault" abbricht...
Was macht den das cp der ds-Busybox nun "anders"? Im menuconfig konnte ich nichts weiter dazu finden. Sollte man sicherheitshalber das rc.S so umschreiben, dass es "cat" statt cp benutzt, oder bin ich der einzige, bei dem das so ist?
Jörg
auf meiner Eumex hatte ich ein interessantes Problem/Phänomen:
Die Einstellungen, die ich im Telefonie-Bereich gemacht hatte (eigene Rufnummer, Telefone) waren nach jedem Neustart weg. Das hat mich, da ich den Part eher selten nutze (außer zum "Fritz-Faxen") nicht so sehr gestört, aber dann doch neugierig gemacht.
Folgenden fand ich heraus:
Beim Booten prüft das rc.S Skript, ob in den gerade erzeugten Nodes im Flash was drin ist, wenn nicht, werden die defaults geladen ("copy_telefonie_defaults fx_conf ${OEM} ${Country} ${OEM_DEFAULT_INDEX"). Dabei geht das Skript so vor, dass die Defaults per "cp" dorthin kopiert werden. Mit dem Resultat, dass die Specila-Devicces "verschwinden" und "normale" Dateien erstellt werden. Alle Änderungen gehen so natürlich verloren.
Beim Hochfahren sieht das dann so aus:
Code:
mknod: /var/flash/ar7.cfg: File exists
Loading /var/flash/ds_mod...done.
Loading passwords...done.
Loading hosts...done.
Loading config...done.
Loading modules...done.
checkempty: : No such file or directory
cp /etc/default.049/telefon_misc.default /var/flash/telefon_misc
checkempty: : No such file or directory
cp /etc/default.049/fx_lcr.default /var/flash/fx_lcr
checkempty: : No such file or directory
cp /etc/default.049/fx_conf.default /var/flash/fx_conf
checkempty: : No such file or directory
cp /etc/default.049/fx_moh.default /var/flash/fx_moh
cp /etc/default.049/fx_moh.default /var/fx_moh
attempting to load DSL Firmware '/lib/modules/ar0700xx.bin'Das konnte ich nun umgehen, indem ich die Datei gelöscht habe, mit mknod das Device angelegt habe, mit "cat" die defaults hineingeschreiben habe (was ja eigentlich auch "richtiger" wäre als cp, oder?!?) und, siehe da, die Änderungen waren "resetfest".
Soweit, so schlecht. Meine Frage war: WARUM ?!?
Ich habe festgestellt, mit der originalen 04.33-er Firmware geht es mit "cp" beim 2.6-er nicht. Kann das jemand nachvollziehen??
Code:
/var/flash $ rm fx_conf
/var/flash $ mknod /var/flash/fx_conf c 240 $((0x81))
/var/flash $ ls -l
[...snip...]
crw-r--r-- 1 root root 240, 129 Jun 20 12:03 fx_conf
crw-r--r-- 1 root root 240, 99 Jan 1 2000 fx_def
-rwxr-xr-x 1 root root 6356 Jan 1 2000 fx_lcr
-rwxr-xr-x 1 root root 32768 Jan 1 2000 fx_moh
[...snip...]
/var/flash $ cp /etc/default.049/fx_conf.default fx_conf
/var/flash $ ls -l
[...snip...]
-rwxr-xr-x 1 root root 20072 Jun 20 12:04 fx_conf
crw-r--r-- 1 root root 240, 99 Jan 1 2000 fx_def
-rwxr-xr-x 1 root root 6356 Jan 1 2000 fx_lcr
-rwxr-xr-x 1 root root 32768 Jan 1 2000 fx_moh
[...snip...]
/var/flash $ rm fx_conf
/var/flash $ mknod /var/flash/fx_conf c 240 $((0x81))
/var/flash $ cat /etc/default.049/fx_conf.default > fx_conf
/var/flash $ ls -l
[...snip...]
crw-r--r-- 1 root root 240, 129 Jun 20 12:04 fx_conf
crw-r--r-- 1 root root 240, 99 Jan 1 2000 fx_def
-rwxr-xr-x 1 root root 6356 Jan 1 2000 fx_lcr
-rwxr-xr-x 1 root root 32768 Jan 1 2000 fx_moh
[...snip...]
/var/flash $Mit einer "originalen" Firmware geht es, es scheint also am "ds-mod Busybox cp" zu liegen???
Code:
# ls -l
[...snip...]
crw-r--r-- 1 0 0 240, 132 Jan 1 2000 fx_cg
crw-r--r-- 1 0 0 240, 131 Jan 1 2000 fx_moh
crw-r--r-- 1 0 0 240, 130 Jan 1 2000 fx_lcr
crw-r--r-- 1 0 0 240, 129 Jan 1 2000 fx_conf
[...snip...]
#
# cp /etc/default.049/fx_conf.default fx_conf
#
# ls -l
[...snip...]
crw-r--r-- 1 0 0 240, 132 Jan 1 2000 fx_cg
crw-r--r-- 1 0 0 240, 131 Jan 1 2000 fx_moh
crw-r--r-- 1 0 0 240, 130 Jan 1 2000 fx_lcr
crw-r--r-- 1 0 0 240, 129 Jan 1 2000 fx_conf
[...snip...]
#
Code:
/var/flash $ /tmp/cp
BusyBox v1.1.2 (2007.03.12-13:19+0000) multi-call binary
Usage: cp [OPTION]... SOURCE DEST
Copies SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.
-a Same as -dpR
-d,-P Preserves links
-H,-L Dereference all symlinks (implied by default)
-p Preserves file attributes if possible
-f force (implied; ignored) - always set
-i interactive, prompt before overwrite
-R,-r Copies directories recursively
/var/flash $ /tmp/cp /etc/default.049/fx_conf.default fx_conf
Segmentation fault
/var/flash $Was macht den das cp der ds-Busybox nun "anders"? Im menuconfig konnte ich nichts weiter dazu finden. Sollte man sicherheitshalber das rc.S so umschreiben, dass es "cat" statt cp benutzt, oder bin ich der einzige, bei dem das so ist?
Jörg
