PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ohne die ständigen Rückversicherungen weiter ... die mksquashfs.c_save-irgendwas ist einfach von make beim Cleanup vor dem erneuten Auspacken der Quellen gelöscht worden, das ist vollkommen normal - daher war die Sicherung der "originalen" Datei in diesem Verzeichnis wenig hilfreich und man braucht sie eigentlich weder für Vergleiche noch für das Wiederherstellen des vorherigen Zustands, weil man sie einfach erneut auschecken kann.
Nach dem jetzt fälligen Packen der Firmware durch "fwmod" (das neue mksquashfs wurde lt. Protokoll ja erzeugt) kann man noch einmal einen Kontrollblick in die erzeugte Image-Datei werfen (die "raw"-Version), wenn man das unbedingt will und sowohl den Superblock als auch den letzten Block prüfen ... ansonsten einfach installieren lassen und schauen, ob es geht.
Wenn man ständig irgendwelche alten Stände sichert und immer wieder von vorne nachsieht, ob das "patch"-Kommando auch tatsächlich das getan hat, was es mit "patching file ..." zum Ausdruck bringen wollte, dann blickt am Ende niemand mehr durch den Wust an Kommandos durch. Ich habe zwar mal bemerkt, daß das alles auf einmal ausgeführt und getestet werden soll/muß, dabei hatte ich aber mehr ein Szenario im Auge, wo man bis zu einem Fehler vorwärts arbeitet und dann von dort rückwärts nach der Ursache sucht. Das geht nicht immer (weil so ein Neustart eben auch Zwischenergebnisse "vernichtet"), aber wenn man vor lauter Prüfungen (die dann auch noch Phantomfehler aufzeigen anstelle von echten Problemen) gar nicht mehr durchsieht, ist das auch alles andere als hilfreich.
Die Zwischenstände auf dem Buildsystem bleiben ja auch dann erhalten, wenn die FRITZ!Box neu gestartet werden muß ... das kann man dann also immer noch alles prüfen (vorausgesetzt, die Kommandos werden ohne Fehlermeldungen abgearbeitet), wenn das Ergebnis erneut nicht das erwartete ist. Aber das hier wird irgendwie immer mehr das beliebte Gesellschaftsspiel "Ich packe meinen Koffer und nehme mit ..." - ich persönlich kriege jedenfalls langsam Knoten im Hirn, weil es eben immer noch nicht besser geworden ist mit der Lesbarkeit der ellenlangen Protokolle der Abarbeitung.
Wenn es nicht bald klappen sollte, würde ich doch darum bitten, da zwischen den einzelnen Kommandos jeweils einen neuen "CODE"-Block aufzumachen, dann kann man auch viel leichter sofort die Ausgabe jedes einzelnen Kommandos beim Kopieren in den Beitrag noch einmal selbst kritisch beäugen, ob das Ergebnis plausibel ist oder nicht.
Ich verstehe z.B. überhaupt nicht, warum da im ersten CODE-Block in #140 dasselbe Kommando beim vierten Aufruf (ohne daß man dazwischen etwas sehen kann) dann ein anderes Ergebnis liefert als bei den ersten dreien ... da stimmt entweder das Listing nicht oder es gibt doch den "deus ex machina", der die Ergebnisse nach Gusto beeinflußt.
Nach dem jetzt fälligen Packen der Firmware durch "fwmod" (das neue mksquashfs wurde lt. Protokoll ja erzeugt) kann man noch einmal einen Kontrollblick in die erzeugte Image-Datei werfen (die "raw"-Version), wenn man das unbedingt will und sowohl den Superblock als auch den letzten Block prüfen ... ansonsten einfach installieren lassen und schauen, ob es geht.
Wenn man ständig irgendwelche alten Stände sichert und immer wieder von vorne nachsieht, ob das "patch"-Kommando auch tatsächlich das getan hat, was es mit "patching file ..." zum Ausdruck bringen wollte, dann blickt am Ende niemand mehr durch den Wust an Kommandos durch. Ich habe zwar mal bemerkt, daß das alles auf einmal ausgeführt und getestet werden soll/muß, dabei hatte ich aber mehr ein Szenario im Auge, wo man bis zu einem Fehler vorwärts arbeitet und dann von dort rückwärts nach der Ursache sucht. Das geht nicht immer (weil so ein Neustart eben auch Zwischenergebnisse "vernichtet"), aber wenn man vor lauter Prüfungen (die dann auch noch Phantomfehler aufzeigen anstelle von echten Problemen) gar nicht mehr durchsieht, ist das auch alles andere als hilfreich.
Die Zwischenstände auf dem Buildsystem bleiben ja auch dann erhalten, wenn die FRITZ!Box neu gestartet werden muß ... das kann man dann also immer noch alles prüfen (vorausgesetzt, die Kommandos werden ohne Fehlermeldungen abgearbeitet), wenn das Ergebnis erneut nicht das erwartete ist. Aber das hier wird irgendwie immer mehr das beliebte Gesellschaftsspiel "Ich packe meinen Koffer und nehme mit ..." - ich persönlich kriege jedenfalls langsam Knoten im Hirn, weil es eben immer noch nicht besser geworden ist mit der Lesbarkeit der ellenlangen Protokolle der Abarbeitung.
Wenn es nicht bald klappen sollte, würde ich doch darum bitten, da zwischen den einzelnen Kommandos jeweils einen neuen "CODE"-Block aufzumachen, dann kann man auch viel leichter sofort die Ausgabe jedes einzelnen Kommandos beim Kopieren in den Beitrag noch einmal selbst kritisch beäugen, ob das Ergebnis plausibel ist oder nicht.
Ich verstehe z.B. überhaupt nicht, warum da im ersten CODE-Block in #140 dasselbe Kommando beim vierten Aufruf (ohne daß man dazwischen etwas sehen kann) dann ein anderes Ergebnis liefert als bei den ersten dreien ... da stimmt entweder das Listing nicht oder es gibt doch den "deus ex machina", der die Ergebnisse nach Gusto beeinflußt.
Code:
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
ls: Zugriff auf check_7360v2_flash_problem_neu.patch nicht möglich: Datei oder Verzeichnis nicht gefunden
frank@frank-ThinkPad-X121e:~/freetz-trunk$ ls -la check_7360v2_flash_problem_neu.patch
-rw-r--r-- 1 frank frank 1403 Jun 9 22:37 check_7360v2_flash_problem_neu.patch