[Gelöst]: sl-mod 1.3 / mit dropbear, ether-wake, vi, sed, crontab, wget, etc.

[olistudent]

Dummerweise kann man keinen eigenen Kernel für die SL bauen. Ich tippe immer noch darauf, dass der Kernel /sbin/init nicht starten kann. Warum auch immer. Man könnte ja mal testweise die original busybox ins tools-Verzeichnis kopieren und schauen was sich dann tut.

MfG Oliver

 

[han-solo]

Ok, ich werde das morgen früh gleich mal testen.
Die Frage ist nur, was wenn es dann immer noch nicht funzt?
So long.....

Gruß
HS

 

[MaxMuster]

Es gibt ja "nur" zwei grundsätzliche Probleme:
- Der Kernel kann init nicht starten, weil das "neue init" in der neuen BB nicht funktioniert (dann sollte es mit der originalen BB klappen)
- Der Kernel kann init nicht starten, weil irgendetwas mit dem erstellten Image nicht stimmt (Fehler im Makefile, bei der Erstellung das squashfs ....) dann würde es auch mit der originalen BB nicht klappen.


Zumindest gibt uns das Ergebnis die Möglichkeit dass die jeweils andere Möglichkeit "ausgeschlossen" oder "unwahrscheinlicher" (Fall eins: Bau der FW ziemlich sicher o.k. / Fall zwei: Vermutlich BB ok vermutlich Problem bei der FW-Erstellung)

Ich habe bei der direkten Durchsicht der Config noch zwei Parameter gefunden, die in den Configs unterschiedlich sind: Puffer über malloc oder Stack und SUID-Feature:

CONFIG_FEATURE_BUFFERS_USE_MALLOC    # in "meiner", das ist noch änderbar
CONFIG_FEATURE_BUFFERS_GO_ON_STACK  # bei "AVM"

und

CONFIG_FEATURE_SUID=y        # in "meiner", das ist im menuconfig [B]nicht änderbar[/B]
CONFIG_FEATURE_SUID=n        # bei "AVM"

Mal sehen, ob ich da nochmal eine neue Busybox baue...


Jörg

 

[han-solo]

Moin,

so jetzt wirds intressant. Die erstellte Firmware mit orginal busybox verhält sich genau wie die anderen erstellen Firmwares. Bleibt also beim booten hängen.

Somit können wir eine nicht funktionierende busybox erstmal ausschließen.
Es muss also im Makefile irgend etwas faul sein.

Ich hab mal meine Sourcen angehängt. Vielleicht könnt ihr es euch mal anschauen. Stimmt vielleicht beim einpacken etwas nicht?

Gruß
HS

 

[han-solo]

So, nach weitern Tests muss ich sagen, dass es wohl am mksquashfs liegen muss.

Ich hab folgendes getestet:

1.) Kernel Test
Vor dem Einpacken das original kernel.image aus org-fw/var/tmp in update/var/tmp kopiert
Ergebnis: Die Box bleibt wie zuvor beim booten hängen

2.) Filesystem Test
Vor dem Einpacken das original filesystem.image aus org-fw/var/tmp in update/var/tmp kopiert
Ergebnis: Die Box bootet ganz seltsam ein Stück weiter und dann ist schluß

8.180.1:53 
CONFIG_CAPI_XILINX='n' successful!eckem     
CONFIG_
Launching kernel decompressor.G_CDROM_FALLBACK='y': sta     
Kernel decompressor was successful ... launching kernel.='y'IG_STOR89]:   
CONFIG_ENVIRONMENT_PATH='/proc/sys/de

LINUX started...  
CONFIG_USB: y
$24: 00000001 941bbdd8                   941ba000 941bbe88 00800000 94063ae0
Hi : 00000000
Lo : 00000400
epc  : 00000000    Not tainted
Status: 1000fc03
Cause : 10800008
Process swapper (pid: 1, stackpage=941ba000)
Stack: 00000000 1000182c 940639e8 94139f91 00000000 941de420 00000000 94139f94
       941bbf30 00000009 94064170 941ca000 9404f1a8 9405e520 94071254 00000000
       94139f91 00000003 0023ee05 00000000 00000000 941ca000 94139f90 00000000
       00000000 94139f88 94139f98 94139f70 94064400 941bbf08 00000000 00000000
       9404f1a8 94004120 9407261c 94072608 00000001 00000000 9404e818 94169000
       9000d35c ...
Call Trace: [<940639e8>] [<94139f91>] [<94139f94>] [<94064170>] [<9404f1a8>] [<9
405e520>]
 [<94071254>] [<94139f91>] [<94139f90>] [<94139f88>] [<94139f98>] [<94139f70>]
 [<94064400>] [<9404f1a8>] [<9407261c>] [<94072608>] [<9404e818>] [<9402806c>]
 [<9402806c>] [<94139f98>] [<94028060>] [<94028058>] [<9402806c>] [<94028084>]
 [<94027e2d>] [<940789d8>] [<94028a4c>] [<94028020>] [<94028a3c>]

Code: (Bad address in epc)

Kernel panic: Attempted to kill init!
Rebooting in 5 seconds..

Gruß
HS

 

[MaxMuster]

Hi,

ich wäre mir nicht so sicher, dass er tatsächlich "weiter" bootet, sondern da ist nun "müll" an einigen Stellen:

Du hast (wenn ich das richtig verstanden habe) den ersten Teil des Filesystems (der Part, den noch hinter den Kernel passte) von dem selbst erzeugten Filesystem mit dem zweiten Teil des original-FS "vermischt". Das kann eigentlich nicht gutgehen...


EDIT könntest du mal das beiliegende Makefile testen? Das sollte nichts weiter tun, las das Image aus- und wieder einzupacken. Zwei Dinge zum "original" habe ich verändert: Vom Filesystem.image auch die Checksum entfernt, bevor ich es mit dem anderen zusammengepackt habe und bei update aus -mkdir update ein mkdir update gemacht...


Jörg

 

[han-solo]

Naja, wie gesagt. War ein nur Test.
Hast du eine SL zum testen?

 

[MaxMuster]

... nee, leider nicht, sonst könnte ich ja mehr tun. Ich hatte mich ja ursprünglich nur mal "ganz kurz" eingeschaltet ;-), weil sich keiner fand, dir mal eine Busybox zu kompilieren. Probier doch bitte mal das "nichtstu-Makefile" oben...

Jörg

 

[han-solo]

Läuft bei mir nicht

frt-fra-ws5306:/tmp/slmod # make
rm -rf root-fs
# remove checksum
tools/rmtichksum -f orig-fw/var/tmp/kernel.image
no checksum found.
make: *** [root-fs] Error 2

Edit: Ich habe hier zwei SL Boxen liegen. Wenn ich dir eine schicken würde, wärst du bereit da intensiver mitzuwirken? Lege auch Rückporto mit bei.
Edit: Sorry, vergessen "make clean" zu machen. Jetzt läuft es.
Edit: Sorry, keine Änderung. Die Box bootet nicht

 

[olistudent]

Hi.
Ich denke ich hab das Problem lokalisiert. Der Kernel der SL unterstützt kein Squashfs mit Blocksize 65536. Änder das im Makefile mal ab. Das ist nicht schön, weil mit Blocksize 16384 noch weniger ins Image passt. :-(

MfG Oliver

 

[MaxMuster]

Hi Oli,
in der Richtung habe ich auch gedacht und wollte mir mal das Original-Squashfs aus dem Image mal genauer ansehen. Gibt es eine Möglichkeit, sich die "Interna" (Blocksize, Komprimierung usw) eines squashfs anzeigen zu lassen?
Ein weiterer Punkt: Ob "Hidden Root”, "Hidden SquashFS" oder "Contiguous SquashFS" wird das im Bootloader oder im Kernel "festgelegt"?

Jörg

 

[olistudent]

Du musst die squashfs-tools mit "-DSQUASHFS_TRACE" kompilieren. Hidden Root wird im Bootloader festgelegt. Da ja die größe der mtds davon abhängt. Natürlich brauchst du sowohl für Hidden Root als auch für Hidden Squashfs einen Kernel der mtd1 nach dem Anfang des Squashfs durchsucht. Beim Contiuous Squashfs wir dann einfach aus Hidden Squashfs und Filesystem ein virtueller (?) mtd erstellt.

MfG Oliver

 

[han-solo]

So, hab die Blockgrösse abgeändert.
Schade, jetzt ist das Image zu groß.

# Check Filesystemsize
./checksize
filesystem image size: 1376256 (max: 1310720)
ERROR: filesystem image is 65536 bytes too big
make: *** [update] Error 1

Lässt sich noch irgendwas rauswerfen oder die busybox noch ein klein wenig verkleinern? libcrypt und ar7login hab ich schon rausgelassen. Aber ihr seht ja, noch zu groß.

Gruß
HS

 

[MaxMuster]

Mal sehen, was ich morgen noch machen kann.
Was drin ist, weisst du ja, dann musst du sagen, was weg soll (recht groß ist z.B etherwake)..
Aber versuche doch bitte mal das ganze mit der originalen BB um zu sehen, dass es so prinzipiell funktioniert.

Jörg

 

[han-solo]

Also verzichten kann ich auf anhieb auf:

- ftpget
- ftpput
- halt
- poweroff
- traceroute

Wenn das nicht reicht, dann können wir ether-wake immernoch rauswerfen.
Danke schonmal... Ich teste morgen früh gleich mit der original busybox.

 

[MaxMuster]

Ich kann doch so nicht ins Bett gehen ;-)

Also, o.k., weg ist nun folgendes:

- ftpget
- ftpput
- halt
- poweroff
- traceroute

find:
- enable -print0
- enable ...time matching
- enable permission
- enable filetype-matching
- enable stay in FS
- enable newer
- enable inoder-number matching
- enable -exec

ash:
- Posix math support
- builtin echo
- builtin test

ifconfig:
- enable hw (setting einer MAC)

crond:
- enable -d

Das reicht aber nur, wenn du noch beherzt auf dein USB verzichtest, und das Modul einfach löscht. Nebenwirkungen????
(Dafür hab ich die libcrypt noch drin gehabt...)

        echo "delete unimportant files"
        rm -R root-fs/usr/www/all/html/de/help
        rm -R root-fs/usr/www/all/html/de/usb
        rm -R root-fs/usr/www/all/html/de/wlan
        rm -R root-fs/usr/www/all/html/de/fon
        rm -R root-fs/etc/default.Fritz_Box_2MB/1und1
+       rm -R root-fs/lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/net/avalanche_usb
        ln -s avm root-fs/etc/default.Fritz_Box_2MB/1und1

Jörg

 

[han-solo]

Moin Jörg,

super Aktion von dir. Vielen Dank.
Es sieht jetzt schon besser aus. Allerdings vermute ich, du hast ie busybox nicht mit "-static-libgcc" kompiliert. Denn ich bekomme beim Booten folgenden Fehler:

LINUX started...
Config serial console: ttyS0,38400
This SOC has MDIX cababilities on chip: HWRevision="F"
AutoMDIX="<unknown>"
MDIX disabled.
initKernel panic: Attempted to kill init!
: can't load library 'libgcc_s.so.1'
Rebooting in 5 seconds..

Edit: Mit der original busybox funzt es jetzt. Great!

Gruß
HS

 

[MaxMuster]

War wohl etwas zu spät gestern. Wie ist es hiermit?!?

Jörg

 

[han-solo]

Hallo Jörg,

irgend etwas ist noch faul. Die Box bootet, bleibt dann aber mit folgendem Fehler stehen und die LAN LED bleibt aus.

ermittle die aktuelle TTY
tty is "/dev/tts/0"
-sh: stty: not found
Serielles Terminal

Ich hab mal zum Test ein paar HTML-Files gelöscht und das Image mit der vorherigen busybox erstellt. Damit funzt es, aber nach ein paar Minuten rebootet die Box von selbst.

Noch irgendwelche Ideen?

Gruß
HS

 

[MaxMuster]

Tja, aber stty war nicht im "alten" oder originalen BB-Binary mit drin...
Ich habe jedoch die ash-internen Befehle "echo" und "test" abgewählt. Ob es daran lag? Hier mal zwei neue BBs eine wie vorher +stty und eine wie vorher mit ash-internem echo und test.

Jörg