Update bleibt hängen

[heikothole]

Hallo ihr,

ich habe vor ein paar Tagen zum ersten Mal einen dsmod (ds26-15.1) auf meiner FB aufgespielt. Nun habe ich mir ein neues Image zusammengestellt. Ich habe OpenVPN rausgenommen und dnsmasq dazugenommen (mit make menuconfig).

Nachdem das Image mit make erstellt wurde, wollte ich es auch aufspielen. Allerdings bleibt die FB immer auf der Seite stehen wo ich den Pfad zur Datei angebe und auf Update starten klicke. Dann geht die DSL-Verbindung verloren und die Info-LED blinkt bis in alle Ewigkeit. Auch meine Verbindung per ssh geht nicht mehr.

Jetzt habe ich mir mal nach einem Neustart der FB per ssh die Ausgabe von free angeguckt:

/var/tmp $ free
              total         used         free       shared      buffers
Mem:       14124       13164       960               0          332
Swap:            0             0           0
Total:      14124       13164       960

Wenn ich das richtig verstehe, dann hat die FB nicht mal mehr 1 MB frei. Aber das Image ist fast 4 MB groß. Kann das überhaupt klappen?

Was kann ich machen?

Gruß
Heiko

[MaxMuster]

Vor dem Update openvpn (und alle anderen "dsmod-Dienste") stoppen...

Jörg

[kriegaex]

Oder per tools/push_firmware.sh via ADAM-FTP flashen. Da hast Du die Gewähr, daß noch kein Dienst läuft.

[heikothole]

Hallo,

ich kann nicht so viel stoppen bis ich genügend freien RAM habe. Oder was kann ich alles stoppen? Was muss denn unbedingt noch laufen?

Ich habe mir mal kurz tools/push_firmware.sh angeguckt.
Sehe ich das richtig, dass das Script dann die FB über die IP 192.168.178.1 ansprechen will? Meine FB ist aber eigentlich im LAN unter 192.168.0.1 erreichbar. Ist der bootloader nur unter der 192.168.178.1 zu erreichen? Kann ich das ändern? Oder muss ich mein ganzes LAN auf das Subnet 192.168.178 umstellen?

Danke
Heiko

[kriegaex]

Ich habe mir mal kurz tools/push_firmware.sh angeguckt.

Das war aber ein sehr kurzer Blick. Da hättest Du lieber länger geschaut oder das Programm einfach aufgerufen, das wäre netto weniger aufwendig gewesen, als im Forum zu fragen:

$ tools/push_firmware.sh 

Usage: tools/push_firmware.sh <firmware> [ -f ] [ <ip> ]

firmware    firmware file to flash (mostly kernel.image)
-f          disable safety prompt
ip         bootloader IP address (default: 192.168.178.1)

D.h., Du kannst auch eine andere IP angeben. Der Bootloader hat allerdings tatsächlich u.U. eine andere Adresse als die gebootete Box. Welche genau (meistens 192.168.178.1), kriegst Du so heraus:

$ cat /proc/sys/urlader/environment | grep my_ip
my_ipaddress    192.168.2.1

Ändern kann man diese Adresse auch, aber nur über Bootloader-FTP, soweit ich mich erinnere (zu faul zum Probieren). Du hast Recht mit der Vermutung, daß der PC, von dem aus Du per push_firmware flashen möchtest, im entsprechenden Subnetz sein muß (nur der eine PC, nicht das ganze Netz).

Keiner zwingt Dich, push_firmware zu verwenden, wenn es Dir zu aufwendig erscheint. Es war nur ein Vorschlag. Mir persönlich wäre es zu aufwendig, zigmal zu versuchen, es über Web-UI zu machen. Geschmackssache.

[olistudent]

Man kann die Adresse genau wie jede andere Variable ändern.

echo my_ipaddress 192.168.0.1 > /proc/sys/urlader/environment

MfG Oliver

[kriegaex]

Wie gesagt, ich war zu faul zum Probieren, ob das einen Reboot überlebt. Auch die Seriennummer kann man ja so ändern, nur ist die nach dem Reboot wieder wie vorher.

[MaxMuster]

[klugscheiß]
Auch wenn es weiter abgleitet:
Ist m.W. aber erst mit dem neuen EVA so. Es lassen sich halt einige Dinge nicht "resetfest" ändern, weil die vom Bootloader beim Start aus den im Loader gespeicherten Werten wiederhergestellt werden.
Vermutlich alle Dinge, die in den Bootloader hineingeschrieben werden:

maca                    overwrite
macb                    overwrite   
macwlan                 overwrite
macdsl                  overwrite
usb_board_mac           overwrite
usb_rndis_mac           overwrite
bluetooth               overwrite
reserved                overwrite      
HWRevision              overwrite
ProductID               overwrite
SerialNumber            overwrite
usb_device_id           overwrite
usb_revision_id         overwrite
usb_manufacturer_name   overwrite
annex                   overwrite

[/klugscheiß]

Jörg

[kriegaex]

[klugscheiß-ergänz]
Also dann, wenn wir das schon andiskutieren, damit der Hintergrund auch klar ist:

• Warum das so ist
• Wie man das trotzdem ändern kann

[/klugscheiß-ergänz]

[knox]

[offtopic]
Ihr seid süß
[/offtopic]

[MaxMuster]

Hi,

@knox: Sorry, der muss jetzt sein Danke für die Blumen, aber: "Bitte nicht off-topic posten"

@Alexander: Bitte übernehmen (oder nur merken, man weiss ja nie, wofür es gut ist) und dann diesen Post löschen

Nur um es dann auch komplett zu machen, das Ändern des Environments für diese speziellen Dinge geht auch direkt mit den 2.6-er libs. In dem letzten Image der "Classic" Fritzbox Fon (06.04.33) ist ein urlader.setconfig26 (warum steht in dem besagten Thread), damit geht es noch entspannter, weil man keine libs mehr kopieren muss (o.k., steht prinzipiell auch schon eine Seite später).

./urlader.setconfig26 -i urlader.config -u /dev/mtdblock3 -e /proc/sys/urlader/environment

Jörg

[heikothole]

Hallo,

ich habe versucht meine FB mit push_firmware.sh upzudaten. Dazu habe ich zuvor wie von olistudent beschrieben die IP des Bootloaders geändert.

Die Ausgabe von push_firmware.sh sah so aus:

heiko@heikoserver:~/fb/fb/ds26-15.1/tools$ sudo ./push_firmware.sh /home/heiko/fb/fb/ds26-15.1/3130_04.34-ds26-15.1.de_20070714-204532.image 192.168.0.1

!!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
!!!   THERE IS NO WARRENTY AT ALL !!! USE AT YOU OWN RISK   !!!

Are you sure, that you want to flash /home/heiko/fb/fb/ds26-15.1/3130_04.34-ds26-15.1.de_20070714-204532.image directly to mtd1?

proceed (y/n)

 * You should now reboot your box.
   Waiting for box to shut down.
   Tip: switch off, if reboot is not detected because it happens too quickly


 * No reply from box. Assuming switch-off or restart.
   Trying to re-detect box.
   ......

 * Box is back up again.
   Initiating transfer.
   Tip: switch off/on box several times, if FTP client cannot log in ...

Debugging on (debug=1).
---> TYPE I
---> MEDIA FLSH
---> PASV
---> STOR mtd1
---> REBOOT
Close Data connection first
---> QUIT
Close Data connection first

Wärend des Updates war zuerst die Power-Led langsam am blinken und die Info-Led aus, dann war die Power-Led schneller am blinken und die Info-Led auch an zum Schluss war die Info-Led dann wieder aus. So blieb die FB dann.
Nachdem ich dann die FB neu gestartet habe (Netzteil raus) fing erst die Power-Led an zu blinken, dann geht sie wieder aus und die Info-Led fängt an zu blinken. Mehr passiert nicht.

Hat jemand ne Idee was das sein kann? Und wie ich die FB wieder zum Leben erwecke?

Danke
Heiko

[kriegaex]

Sieht erst mal so aus, als wäre das Update erfolgreich gewesen. Im Zweifel evtl. einfach nochmal probieren. Es könnte auch einfach sein, daß die Box nicht durchstartet, weil die neue FW erfolgreich geflasht wurde und es da ein grundsätzliches inhaltliches Problem oder eine Unverträglichkeit mit Deinen Startdateien (debug.cfg, rc.custom) gibt. Das weiß ich nicht.

Was hilft, ist im Zweifel das Flashen einer funktionierenden FW nach derselben Methode oder als Eskalationsstufe 2 ein Full Recover.

[heikothole]

Ich habs gelöst.
Ich habe erst immer versucht das image was bei make rauskam zu instalieren. Dann habe ich mal in das Image reingeguckt und im Verzeichnis tmp eine kernel.image gefunden und diese dann per push_firmware.sh übertragen. Und siehe da, es klappt!!

Ich denke, das war mein Fehler.

Ich habe dazu auf meinem Windows-PC das Image mit 7Zip ausgepackt. Kann man das auch unter Linux? Was ist das für ein Archiv?

Danke für eure Hilfe.
Heiko

[kriegaex]

Ja, das war definitiv Dein Fehler. An sowas hatte ich nicht gedacht. Firmware-Images sind einfache, ungepackte Tar-Archive, die Du mit

tar xvf mein.image

entpacken kannst.

[RalfFriedl]

Das ist ein tar-Archiv, und die Datei, die Du auspacken willst, und die geflasht werden muß, steht schon unter build/modified/firmware/var/tmp/kernel.image

build/modified/firmware ist nämlich das Verzeichnis, das mit tar als Firmware-Update gepackt wird.

@kriegaex
Man könnte beim push_firmware.sh auch dazuschreiben, daß man vermutlich die Datei build/modified/firmware/var/tmp/kernel.image übertragen will.

Also aus dem ds-mod-Verzeichnis so aufrufen:

tools/push_firmware.sh build/modified/firmware/var/tmp/kernel.image

[kriegaex]

OT: Na, Ralf, Hase und Igel heute? Ich war schon wieder ein paar Minuten schneller. Dieses Mal lösche ich aber nicht.

On-Topic-Update:

Man könnte beim push_firmware.sh auch dazuschreiben, daß man vermutlich die Datei build/modified/firmware/var/tmp/kernel.image übertragen will.

Das steht schon lange dabei, einfach mal das Skript ohne Parameter aufrufen und Info lesen.

Demnächst gibt's eine Heuristik, die überprüft, ob das Image auch wirklich ein kernel.image sein kann (Prüfung von vier "magic bytes" am Dateianfang). Das habe ich gerade auf Olivers Anregung hin eingebaut. Desweiteren wird, falls die Prüfung fehlschlägt, sogar noch geschaut, ob es sich um ein Tar-Archiv handelt, das eine Datei ./var/tmp/kernel.image enthält. Falls ja, wird ein zusätzlicher Hinweis gedruckt. Das sieht dann in etwa so aus:

$ tools/push_firmware.sh irgendein.image

Error: file is not a valid image to be written to mtd1. Please use a
hidden root 'kernel.image' containing both Linux kernel and file system.

Hint: file seems to be a full firmware image archive in 'tar' format
containing the 'kernel.image' you are looking for. Please extract the archive
by means of 'tar xf', then call this script again upon the extracted 
'kernel.image'.