7390: volles PHP-Packet -> Reboot-Loop

[rj.2001]

Hallo,

ich wollte mir ein PHP-FTP auf meine Box (aktuelles Trunk mit aktueller Firmware) laden, da die NAS in Verbindung mit vsftpd nicht funktioniert.
vsftpd desswegen, da ich mehrere Nutzer für mein FTP brauche.
PHP-FTP weil ich meistens hinter einer Firewall sitze, welches kein FTP durchlässt, klar man könnte jetzt www.web2ftp.de benutzen, aber sämtliche offiziellen Domains welche einen FTP-Upload zulassen sind von unserer Firewall gesperrt (private Sites jedoch nicht).
Gesagt getan, PHP-FTP-Client auf die Box. Und gestartet. Hierbei stellte sich raus, dass das PHP in der org. Konfiguration "nur" eine abgespeckte Variante ist.
Also die zusätzlichen Packete im Freetz aktiviert (z.B. Session und und und), neues Image gebaut und rauf auf die Box.
Nun endet dies jedoch in einem permanenten Reboot-Loop.
Soll, heisen. Image wird geflasht, Box startet irgendwann neu, rechte LED leuchtet grün. Asnchließend gehen alle LED's an und die Box startet neu.
Das geht nun ewig immer weiter. Muss also mit irgend einem PHP-Zusatz zusammenhängen.

Ist evtl. irgend jemandem etwas bekannt, woran das liegen könnte, bzw. welches Packet das verursacht?


Danke schon mal.

Ciao

 

[er13]

Was verwendest Du als Build-System, SuSE 11.3? s. diesen Thread

 

[rj.2001]

Als Build-System verwende ich den VM-Ware-Player (freetz-linux) auf einer Intel-CPU (Q9950).
Scheint also nicht das Problem zu sein, soweit wie ich das rausgelesen habe, hat es in Deinem vorgeschlagenem Thread nur die Suses betroffen.

Wähle ich aber dann die zugewählten Packete wieder ab und mache ein Package Clean + ein Make so funktioniert das neu erstellte Image einwandfrei auf der Box.

Ciao

 

[RalfFriedl]

Und der Unterschied zwischen den beiden Versionen ist ... ?
Wird PHP bei Dir gestartet (als Bestandteil eines Web-Servers)? Wenn ja, stelle mal den Start auf manuell.

 

[olistudent]

Kannst du mal bitte den Unterschied zwischen den beiden .configs anhängen? Oder beide, wenn du mit diff nicht zurecht kommst.

Gruß
Oliver

 

[rj.2001]

Werde heute Abend mal die beiden configs anhängen.
Bin nur leider momentan nicht mal ansatzweise in der Nähe meines Rechners mit der VM.

Zu den Reboots und PHP auf manuell setzen:
macht irgendwie keinen Sinn, denn die Box kommt ja nicht mal soweit. Nach ca. 10 Sekunden ab einstecken des Netztsteckers ist Ruhe und die Box macht einen Neustart...


Achso: als WebServer nutzte ich lighttpd.
In der abgespeckten PHP-Version steht der Dienst auch immer auf stopped.
Dieser wird ja auch nur (als App) gestartet, wenn tatsächlich ein PHP-Script läuft. Oder irre ich da?
Zumindest eine Testseite auf der Box in PHP funktioniert einwandfrei.
Aber wie gesagt, die Std-Packete reichen mir nicht aus, ich brauche da schon ein paar mehr.

Ciao

 

[RalfFriedl]

Wenn sie schon nach 10 Sekunden neu startet, ist etwas grundsätzliches nicht in Ordnung.
Versuche es mal mit der kleinen Konfiguration und das große Programm nur ins RAM der Box zu laden.

 

[rj.2001]

Hier mal die beiden Configs.
Hab Sie komplett angehangen, vielleicht besteht ja auch eine Abhängigkeit mit einem anderem Packet?!?!?
mit der .klein funktioniert die Box. mit der .komplett stürtzt sie ab.

@RalfFriedl
wenn Du mir jetzt noch sagst, wie ich das PHP auf die Box bekomme, ohne es komplett in das Image reinzubauen und dann dort einzeln starte, mach ich das auch.
Ich denke aber mal, dass es nicht das gleiche ist, als wenn das komplette PHP in die Box eingebaut wird. Denn soweit ich weis ergeben sich durch die Benutzung von PHP auch ein paar andere abhängigkeiten? Oder?!?!?

Ciao

 

[rj.2001]

Kleiner Nachtrag,
wähle ich SQLITE 3 als zusätzliches Packet an passiert das gleiche:
rote LED blinkt 3 Sekunden, dann ist 5 Sekunden die Power LED an, danach gehen alle LED's an und der Spaß beginnt von vorn.
Da SQLITE im Test-Bereich ist, fand ich das aber eher nicht erwähnenswert.
Aber moment mal, ich habe gerade gesehen, das ich SQLITE ausversehen auch als PHP feature angewählt.
Wie soll dieses funktionieren, wenn die BINs bereits schon abstürtzen.
Werde heute Abend mal immer ein neues feature dazu nehmen (ausgenommend er SQL's) mal sehen obs dann nicht mehr abstürzt. Falls doch, hab ich zumindest den verantwortlichen.
Das kann aber ein wenig dauern.... 7 Images bauen, immer wieder neu flashen.

Ciao

 

[er13]

Ich glaube wir haben noch ein Versuchskaninchen (nicht böse gemeint) für dieses Ticket.

@rj.2001:
Könntest Du bitte ein Image mit der "großen" .config bauen (nur bauen, nichts flashen) und die Ausgabe von

find build/modified/filesystem -type f -empty
und
find build/modified/filesystem -type f -exec md5sum -b \{\} \+ | sort -k 2 (Edit: . durch build/modified/filesystem ersetzt)

hier anhängen.

Danach

1. diesen Patch anwenden
2. make squashfs3-distclean aufrufen
3. das Image nochmal bauen
4. die beiden find-Befehle oben nochmal ausführen und die Ausgaben wieder anhängen.

Wenn Du irgendwelche kaputten Images hast, lösche sie bitte vorerst nicht. Eventuell werden wir Dich bitten, uns diese zu Analyse-Zwecken zur Verfügung zu stellen. Danke!

Edit: und mit der kleinen .config kannst Du auch noch ein Image bauen und die Ausgaben von den finds anhängen.

 

[cuma]

Ich hab übrigens ähnliche CPU, auch "Core 2 Quad". Nur bisschen langsamer.

 

[rj.2001]

Hallo,

Getestet wurde wie folgt:
* ich habe die .config der PHP-Std-Version gesichert (nur SSL- und XML-Support)
* anschließend habe ich immer ein Packet hinzugewählt
* das Image erstellt
* die o.g. Sicherung wieder zurück kopiert und das nächste Packet selektiert
* als alle Images erstellt waren, habe ich die Box hintereinander geflasht.
hier nun die Ergebnisse:

Datei-Größe : Dateigröße der erstellten image Datei
KImage-Größe: Dateigröße folgender Datei im Image: var/tmp/kernel.image

Packet	Funktioniert  Datei-Größe  KImage-Größe
CURL       JA          16216576    15479048
GD        NEIN         16491008    15753480
ICONV      JA          16122368    15384840
JSON       JA          16118272    15380744
PCNTL      JA          16110080    15372552
SESSION    JA          16126464    15388936
SOCKET     JA          16122368    15384840
SQLv2      JA          16212480    15474952
SQLv3     NEIN         16364032    15626504
SYSVIPC    JA          16118272    15380744
ZLIB       JA          16114176    15376648

Nun habe ich alle funktionierenden Packete in ein Image zusammengefasst, dieses funktioniert jedoch auch nicht:

Packet	Funktioniert  Datei-Größe  KImage-Größe
All_JA    NEIN         16380416    15642888

Nun habe ich ein paar AVM-Packet runter geschmissen, welche ich nicht brauche:
ftpd, NAS-IF, NTFS-Support, Help-Files
Dann 2 Images gebaut, welche oben nicht funktionierten. Das ist das Ergebnis:

Packet	Funktioniert  Datei-Größe  KImage-Größe
GD         JA          16019968    15282440
SQLv3      JA          15897088    15159560

Irgendwie beschleicht mich das Gefühl, dass das ganze was mit der Imagegröße zu tun hat, obwohl keine Fehlermeldung kam.

Also ein Packet gebaut, ohne
ftpd, NAS-IF, NTFS-Support, Help-Files
aber mit allen PHP-Packeten bis auf SQLvX (da mit SQL das Packet scheinbar wieder zu groß geworden wäre):

Packet	Funktioniert  Datei-Größe  KImage-Größe
ALL        JA          16175616    15438088

Im Anhang die beiden Find-Outputs. von einem Packet, welches die folgenden PHP-Packete enthält:
GD, SQLitev3, SSL, XML
Da nach Reduzierung der Imagegröße die beiden Images funktionierten, denke ich mal nicht, das ich ein "neues Versuchkaninchen" sein werde...

Was sagt Ihr zu dieser Erkenntnis?
Wo liegt die maximale Datei-Größe für ein Image für die 7390?

Ciao

 

[RalfFriedl]

Es wäre interessant zu sehen, was auf der seriellen Konsole passiert.
Kann das jemand nachvollziehen, der eine Konsole angeschlossen hat?

 

[rj.2001]

Könnte auch ein defektes Image zur Verfügung stellen...

 

[er13]

Könntest Du bitte diese zwei Images - All_JA/NEIN und ALL/JA - wieder entpacken (fwmod -u) und deren Inhalte vergleichen (z.B. mit Hilfe des zweiten finds). Wenn sie bis auf die rausgeschmiessenen ftpd, NAS-IF, NTFS-Support, Help-Files identisch sind, dann liegt es tatsächlich an der Image-Größe.

 

[olistudent]

Ich hab den Fehler. Kannst du bitte "cat /proc/sys/urlader/environment |grep mtd" von deiner Box posten?
7270:

# cat /proc/sys/urlader/environment |grep mtd
mtd0    0x90000000,0x90000000
mtd1    0x90020000,0x90F80000
mtd2    0x90000000,0x90020000
mtd3    0x90F80000,0x90FC0000
mtd4    0x90FC0000,0x91000000

Gruß
Oliver

edit:

--- Config.in	(revision 6295)
+++ Config.in	(working copy)
@@ -605,13 +605,14 @@
 		FREETZ_TYPE_FON_WLAN_7141 || \
 		(FREETZ_TYPE_FON_WLAN_7170 && ! FREETZ_TYPE_3170_7170) || \
 		FREETZ_TYPE_FON_WLAN_7270_V1
+	default 238 			if \
+		FREETZ_TYPE_FON_WLAN_7390
 	default 246			if \
 		FREETZ_TYPE_FON_WLAN_7240 || \
 		FREETZ_TYPE_FON_WLAN_7270_V2 || \
 		FREETZ_TYPE_FON_WLAN_7270_V3 || \
 		FREETZ_TYPE_FON_WLAN_7320 || \
 		FREETZ_TYPE_FON_WLAN_7340 || \
-		FREETZ_TYPE_FON_WLAN_7390 || \
 		FREETZ_TYPE_FON_WLAN_7570 || \
 		FREETZ_TYPE_WLAN_3270 || \
 		FREETZ_TYPE_WLAN_3270_V3

 

[er13]

Ich würde bei Gelegenheit den Wert auch noch für 7320, 7340 und 7570 überprüfen...

Wo wir über die Image-Größe sprechen... Ich habe mit gcc-4.5.1 einen interessanten Effekt: die mit gcc-4.5.1 kompilierten Dateien sind in der Summe 20 KB kleiner als die mit 4.4.5 kompilierten (jede Datei ist minimal kleiner). Sie lassen sich aber schlechter komprimieren, sodass am Ende ein 10KB größeres Image entsteht.

 

[olistudent]

Die 7340 hat auch 512kb weniger.

Gibts keinen Schalter für "maximale Komprimierbarkeit"?

Gruß
Oliver

 

[RalfFriedl]

Und warum hat sie 256kB weniger? Aus der Definition der mtd-Bereiche oben kommt dies nicht heraus.

 

[olistudent]

Vielleicht hätte ich dazu schreiben sollen, dass die Aufteilung von einer 7270 ist...

edit:
Scheinbar sind die 2 mtds für das tffs größer.

mtd0:                      0x9F000000,0x9F000000
mtd1:                      0x9F020000,0x9FF00000
mtd2:                      0x9F000000,0x9F020000
mtd3:                      0x9FF00000,0x9FF80000
mtd4:                      0x9FF80000,0xA0000000

mtd0:                0 Bytes
mtd1:       15.597.568 Bytes (15.232 kb, 14,9 MB)
mtd2:          131.072 Bytes (128 kb, 0,1 MB)
mtd3:          524.288 Bytes (512 kb, 0,5 MB)
mtd4:          524.288 Bytes (512 kb, 0,5 MB)