Ich hab nach post_install nochmal aufs alte linux_fs_start zurückgestellt und post_install leer gemacht vor dem reboot damit es nicht nochmal ausgeführt wird. Dann ist mtdblock1 nach dem reboot noch mit Inhalt versehen... Dann umgestellt aufs andere linux_fs_start - bootet nicht mehr. adam2 und wieder zurück - und mtdblock1 hat noch Inhalt. Booten tut die Box aber immer noch nicht - oder hab ich jetzt mit dem leeren von post_install (exit 0 hab ich dringelassen) trotz manueller Ausführung das verhindert?
[Gelöst] FW 6.50 für 7490 in Trunk rev. 13490 - keine Auswahlmöglichkeit
- Ersteller JohnDoe42
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Nein, mit dem fehlschlagenden Boot-Vorgang bist Du nun aber wieder am eigentlichen Problem dran ... offenbar war das leere yaff2-Dateisystem die Folge der doppelten Ausführung von "post_install" - nicht ganz überraschend, wenn man sich /var/post_install noch einmal richtig ansieht. Dort wird ja die Ausgangsdatei gelöscht (rm filesystem.image), nachdem der Dummy-Header per dd entfernt wurde und damit findet der "zweite Durchgang" dann kein Filesystem mehr zum Mounten. Zwar schaltet der dann auch nicht auf das andere System um, weil aus seiner Sicht das Flashen nicht funktioniert hat, das hat aber bereits der erste Aufruf nach dem erfolgreichen Speichern im yaffs2-FS übernommen.
Jetzt kann man sich also dem eigentlichen Problem widmen, nachdem man - egal auf welchem Weg - das "conv=sync"-Problem umgangen hat.
So schön (oder meinetwegen systematisch) es ja auch ist, daß hier jetzt schon zwei Leute das "conv=sync"-Problem durch das zusätzliche vorherige Flashen eines Systems mit passendem dd-Applet gelöst haben - es hatte ja hoffentlich niemand von Euch tatsächlich die Hoffnung, daß es auf diesem Weg anstelle des von mir vorgeschlagenen Patches am Ende einen Unterschied geben würde, oder? Ansonsten würde das ja heißen, daß derjenige in meiner Argumentation in #52 eine Lücke gefunden hätte und dann wäre es nur fair, diese Erkenntnis mit mir (bzw. uns) zu teilen.
Als Lösung für andere Freetz-Nutzer macht es sicherlich einen Unterschied, ob man im Trunk einfach die Variante mit dem Entfernen (des meiner Meinung nach eben ohnehin unwirksamen) "conv=sync"-Zusatzes umsetzt oder ob man am Ende jedem bisherigen Freetz-Nutzer sagen muß, er solle vor dem Update auf 06.50 erst einmal ein anderes Image mit einer ordentlichen Busybox erstellen und auf die Box bringen.
Zurück zu einer Untersuchung der Start-Probleme ... nachdem nun ein solches Freetz-Image nicht starten will und per "linux_fs_start" auf die vorherige Version zurückgegriffen wird, was steht denn nun in der crash.log oder auch in der panic.log? Ist die "crash"-Variable im Urlader-Environment leer? Wenn nicht, war sie es vor diesem fehlgeschlagenen Start? Wenn ja, was steht jetzt dort drin?
Ich habe bei anderen Modifikationen (abseits von Freetz) es geschafft, die Box ebenfalls ins Nirwana zu schicken, bei mir war es folgender Fehler:
Da auch ich mangels AVM-Sourcen gerade experimentiere, wie weit man gehen kann beim Austausch von Libraries, bevor einem alles um die Ohren fliegt, könnte hier auch eine inkonsistente Library-Zusammenstellung die Ursache gewesen sein. Aber ich weiß eben auch genau, daß bei mir das System wenigstens schon mal bis zur Abarbeitung der rc.S kommt/gekommen ist ... und diese Prüfung steht m.W. für ein Freetz-Image (wo eben auch die Libs im yaffs2 schon getauscht werden, was bei mir nicht der Fall ist) noch aus.
Sollte also jemand weitere Tipps haben wollen, wie man das testen könnte bzw. was man als nächstes prüfen sollte, gebe ich die gerne (und hoffe inständig, daß sie stimmen und nützlich sind) ... wenn ich das aber ohnehin für die Tonne schreibe (wie #52), dann kann ich mir die Zeit auch sparen.
Jetzt kann man sich also dem eigentlichen Problem widmen, nachdem man - egal auf welchem Weg - das "conv=sync"-Problem umgangen hat.
So schön (oder meinetwegen systematisch) es ja auch ist, daß hier jetzt schon zwei Leute das "conv=sync"-Problem durch das zusätzliche vorherige Flashen eines Systems mit passendem dd-Applet gelöst haben - es hatte ja hoffentlich niemand von Euch tatsächlich die Hoffnung, daß es auf diesem Weg anstelle des von mir vorgeschlagenen Patches am Ende einen Unterschied geben würde, oder? Ansonsten würde das ja heißen, daß derjenige in meiner Argumentation in #52 eine Lücke gefunden hätte und dann wäre es nur fair, diese Erkenntnis mit mir (bzw. uns) zu teilen.
Als Lösung für andere Freetz-Nutzer macht es sicherlich einen Unterschied, ob man im Trunk einfach die Variante mit dem Entfernen (des meiner Meinung nach eben ohnehin unwirksamen) "conv=sync"-Zusatzes umsetzt oder ob man am Ende jedem bisherigen Freetz-Nutzer sagen muß, er solle vor dem Update auf 06.50 erst einmal ein anderes Image mit einer ordentlichen Busybox erstellen und auf die Box bringen.
Zurück zu einer Untersuchung der Start-Probleme ... nachdem nun ein solches Freetz-Image nicht starten will und per "linux_fs_start" auf die vorherige Version zurückgegriffen wird, was steht denn nun in der crash.log oder auch in der panic.log? Ist die "crash"-Variable im Urlader-Environment leer? Wenn nicht, war sie es vor diesem fehlgeschlagenen Start? Wenn ja, was steht jetzt dort drin?
Ich habe bei anderen Modifikationen (abseits von Freetz) es geschafft, die Box ebenfalls ins Nirwana zu schicken, bei mir war es folgender Fehler:
Code:
2015-12-18 15:48:10 [Bus error]
dsl_monitor[3110] crashed at 76ef4f64 (/lib/libc.so.0: memset + 0x54) accessing 0x77109000
Version: 06.50
at: 181020ed v0: 77109000 v1: 00000001
a0: 77109008 a1: 00000000 a2: 00000004 a3: 77109fd8
t0: 00000004 t1: 00000000 t2: ffffffff t3: 770fc000
t4: f0000000 t5: 00000001 t6: 76f73ca0 t7: 77052edc
s0: 77109000 s1: 7710e040 s2: 77094b5c s3: 770a7014
s4: 00000000 s5: 00000000 s6: 00000000 s7: 00000000
t8: 00000299 t9: 76ef4f10
gp: 770b5be0 sp: 7fe8a920 fp: 7fe8aa10 ra: 77073338
[bt] Code: 01003021 24840008 <ac85fff8> 1487fffd
[bt] 77073330 [/lib/libavmcsock.so.2 at 43330] cthreadmem_get_specific + 0x88
[bt] 77048678 [/lib/libavmcsock.so.2 at 18678] slab_cbcontext_free + 0x38
[bt] 77073244 [/lib/libavmcsock.so.2 at 43244] cthreadmem_delete_key + 0xa8
[bt] 7703d414 [/lib/libavmcsock.so.2 at d414]
[bt] 7703d704 [/lib/libavmcsock.so.2 at d704]
[bt] 77090ca8 [/lib/libavmcsock.so.2 at 60ca8]
[bt] 770fcee0 [/lib/ld-uClibc.so.0 at ee0]
[bt] 76f19fec [/lib/libc.so.0 at 5cfec] exit + 0x8c
[bt] 76f1e668 [/lib/libc.so.0 at 61668] __uClibc_main + 0x344
[bt] 00403fe8 [dsl_monitor at 3fe8]
ra on stack 0x7fe8abc0. signal trampoline?
Statistik der Semaphoren:
2015-12-18 15:48:10 [Segmentation fault]
dsl_monitor[3110] crashed at 76f9a4f8 (/lib/libdslsmiface.so.0: dsl_shared_memory_interface_write_crashlog + 0x48) accessing 0x10
Version: 06.50
at: 181020ef v0: ffffffff v1: 76fe7489
a0: 76f99000 a1: fffffffd a2: 76fb3360 a3: 00000001
t0: 00000000 t1: 00001016 t2: 8014c260 t3: fffffff0
t4: 00007fff t5: c1b206cc t6: 00000000 t7: 000000fe
s0: 76fb3360 s1: 00000000 s2: 77094b5c s3: 770a7014
s4: 00000000 s5: 00000000 s6: 00000000 s7: 00000000
t8: 00000080 t9: 76f1e064
gp: 76fb3360 sp: 76ffb060 fp: 7fe8aa10 ra: 76f9a4ed
[bt] Code: 9868 659e <99a4> 99c5 99e6
[bt] 00404770 [dsl_monitor at 4770]
[bt] 76fe841a [/lib/libbacktrace.so.1 at 241a]
ra on stack 0x7fff7008. signal trampoline?
Statistik der Semaphoren:Sollte also jemand weitere Tipps haben wollen, wie man das testen könnte bzw. was man als nächstes prüfen sollte, gebe ich die gerne (und hoffe inständig, daß sie stimmen und nützlich sind) ... wenn ich das aber ohnehin für die Tonne schreibe (wie #52), dann kann ich mir die Zeit auch sparen.
Zuletzt bearbeitet:
Ob mit oder ohne conv=sync sag ich in meinem Leichtsinn macht keinen Unterschied - ich hab das nur ins alte Image reingenommen damit ich vergessen kann jedes mal das script zu editieren - ich denke aber dein Ansatz (auch aufgrund der Argumentation, dass ja Verzeichnisweise kopiert wird) macht Sinn. Wenn wir das einmal am laufen haben würde ich das auch nochmal ohne conv=sync ausprobieren - nur dafür muss die Box ja irgendwie mal zum starten gebracht werden...
crash im environment war vorher leer und ist nachher auch noch leer - crash.log (wenn ich in /var/flash im "alten" System dann auch an der richtigen Stelle bin) ist ebenfalls leer. panic.log gibt es keins - und ob /dev/mtd0ro leer ist kann ich leider nicht genau beantworten, mir fehlt derzeit der Ansatz das ding zu mounten... einfach so gehts nicht weil es kein Blockdevice ist.
Das aktuelle Fehlerbild hat sich übrigens etwas verändert: Ich habe keinen Bootloop mehr (oder zumindest einen anderen), die Power-LED blinkt... leuchtet dann kurz durchgehend und blinkt wieder. Mit leerem Dateisystem kam ein Bootloop der alle LEDs aufblinken lies.
crash im environment war vorher leer und ist nachher auch noch leer - crash.log (wenn ich in /var/flash im "alten" System dann auch an der richtigen Stelle bin) ist ebenfalls leer. panic.log gibt es keins - und ob /dev/mtd0ro leer ist kann ich leider nicht genau beantworten, mir fehlt derzeit der Ansatz das ding zu mounten... einfach so gehts nicht weil es kein Blockdevice ist.
Das aktuelle Fehlerbild hat sich übrigens etwas verändert: Ich habe keinen Bootloop mehr (oder zumindest einen anderen), die Power-LED blinkt... leuchtet dann kurz durchgehend und blinkt wieder. Mit leerem Dateisystem kam ein Bootloop der alle LEDs aufblinken lies.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Schade, die Dateien sollten eigentlich nicht wirklich leer bleiben, wenn da irgendwas im Kernel abstürzt (genau dafür gibt es diese verschiedenen Möglichkeiten vermutlich). Beim Crash- oder Panic-Log kann man auch nicht an der falschen Stelle landen, die sind nur einmal in der Box enthalten und nicht ebenfalls doppelt.
"mtd0ro" kann man z.B. mit "cat" irgendwohin ausgeben ... aber nach Deiner Beschreibung ist da ja jetzt ein Kernel drin. Beim ersten Durchlauf von /var/post_install wurde ja auch das "kernel.image" (anders als "filesystem.image") nicht gelöscht, da war zu erwarten, daß beim zweiten Versuch auch das Schreiben von kernel.image klappt. Das wäre nur als Hinweis relevant geworden, wenn es nicht an der zweimaligen Ausführung von /var/post_install gelegen hätte.
Jetzt wäre es halt interessant, wie sich die Power-LED nach der ersten Aktion (die signalisiert ja nur die fünf Sekunden Wartezeit des Bootloaders auf eine FTP-Verbindung) genau verhält, weil man anhand der Zeitangaben in etwa schlußfolgern könnte, wo der Absturz auftritt.
Ich würde zwei mögliche Ansätze sehen, um das etwas weiter einzugrenzen ... die derzeitige Annahme bei mir ist es eben, daß der Austausch der C-Libs das Problem bereits im yaffs2 verursacht. Um dieser Theorie nachzugehen, könntest Du das yaffs2-FS erst einmal aus einem originalen AVM-Image kopieren (wie das geht, kann man ja aus der /var/install bzw. /var/post_install ableiten) und dann nur die von Freetz erstellte filesystem_core.squashfs in das yaffs2-FS kopieren. Das müßtest Du natürlich weitgehend von Hand mit entsprechenden Shell-Kommandos in der FRITZ!Box machen - Ziel wäre es, bis zum pivot_root erst einmal mit den originalen AVM-Dateien zu arbeiten (Freetz tauscht eben auch da die Libs schon aus) und zu prüfen, ob sich dadurch die Dauer des Loops ändert, was dann darauf hinweisen würde, daß es tatsächlich ein Problem im yaffs2 gibt. Alternativ könnte man auch die Busybox passend zur C-Lib ebenfalls im yaffs2-Image (eigentlich ja im ext2-Image) ersetzen (damit da BB und Libs aus einem Build stammen), wäre aber m.E. nur die zweitbeste Lösung und eigentlich sollte der dynamische Loader das auch glattbügeln, was da event. an Unterschieden existiert.
Ein ganz anderer Ansatz wäre der Vergleich der /dev-Verzeichnisse bei einem originalen AVM-Image und bei dem von Freetz verwendeten Image für die yaffs2-Partition. Wie ich schon weiter vorne geschrieben habe, blicke ich beim Anlegen der Nodes unterhalb von /dev durch Freetz nicht wirklich durch (habe auch nicht den geringsten Ehrgeiz, dort ohne Not zu analysieren) und eine unglückliche Abweichung an dieser Stelle könnte ebenfalls zu Problemen führen ... schon wegen der anderen Arbeitsweise beim 06.50, wo das originale /dev-Verzeichnis per bind-Mount in das System nach dem pivot_root gemountet wird, während es vorher dort ein mount für ein tmpfs gab und die Nodes per tar-Kommando von dem einen Verzeichnis in das andere übertragen wurden. In dieser unterschiedlichen Behandlung könnte m.E. auch noch eine potentielle Stolperfalle für Freetz liegen.
Ich könnte sicherlich auch mal selbst ein Freetz-Image testen ... andererseits gebe ich zu, daß mein eigenes Interesse an einem solchen Image nahe Null liegt und ich das tatsächlich erst als allerletzten Schritt in Erwägung ziehen würde, wenn es keine irgendwie erklärlichen Ursachen mehr gibt. Ansonsten habe ich mit eigenen Tests genug zu tun ... und dabei hänge ich die Box selbst oft genug auf, aber eben erst später.
EDIT: Das "panic.log" ist ggf. nicht als char-Device in /var/flash vorhanden (und müßte angelegt werden), aber über das proc-Interface sollte es auch bei der 06.30 zugänglich sein ... allerdings löscht wohl ein Lesezugriff über das proc-Interface auch gleich den alten Inhalt und so sollte man diesen Lesezugriff gleich in eine Ausgabedatei umleiten. Das ist normalerweise im proc-FS unter /proc/avm_panic_cr und /proc/avm_panic_sd zugänglich (sind wohl auch tatsächlich dieselben Inhalte, zumindest bei der 06.50), bei mir gab es z.B. letztens ein Problem mit einer falschen Busybox bzw. einem fehlenden Symlink, wo dann kein "init" gefunden wurde, aber der eigentliche Fehler sollte schon das fehlgeschlagene Mounten für devtmpfs gewesen sein:
Auf welches System sich so eine Protokollierung jeweils bezieht, sieht man an der Partition-Struktur weiter vorne in diesem Protokoll bzw. an der als yaffs2 gemounteten Partition (oben also das System mit "linux_fs_start=0").
"mtd0ro" kann man z.B. mit "cat" irgendwohin ausgeben ... aber nach Deiner Beschreibung ist da ja jetzt ein Kernel drin. Beim ersten Durchlauf von /var/post_install wurde ja auch das "kernel.image" (anders als "filesystem.image") nicht gelöscht, da war zu erwarten, daß beim zweiten Versuch auch das Schreiben von kernel.image klappt. Das wäre nur als Hinweis relevant geworden, wenn es nicht an der zweimaligen Ausführung von /var/post_install gelegen hätte.
Jetzt wäre es halt interessant, wie sich die Power-LED nach der ersten Aktion (die signalisiert ja nur die fünf Sekunden Wartezeit des Bootloaders auf eine FTP-Verbindung) genau verhält, weil man anhand der Zeitangaben in etwa schlußfolgern könnte, wo der Absturz auftritt.
Ich würde zwei mögliche Ansätze sehen, um das etwas weiter einzugrenzen ... die derzeitige Annahme bei mir ist es eben, daß der Austausch der C-Libs das Problem bereits im yaffs2 verursacht. Um dieser Theorie nachzugehen, könntest Du das yaffs2-FS erst einmal aus einem originalen AVM-Image kopieren (wie das geht, kann man ja aus der /var/install bzw. /var/post_install ableiten) und dann nur die von Freetz erstellte filesystem_core.squashfs in das yaffs2-FS kopieren. Das müßtest Du natürlich weitgehend von Hand mit entsprechenden Shell-Kommandos in der FRITZ!Box machen - Ziel wäre es, bis zum pivot_root erst einmal mit den originalen AVM-Dateien zu arbeiten (Freetz tauscht eben auch da die Libs schon aus) und zu prüfen, ob sich dadurch die Dauer des Loops ändert, was dann darauf hinweisen würde, daß es tatsächlich ein Problem im yaffs2 gibt. Alternativ könnte man auch die Busybox passend zur C-Lib ebenfalls im yaffs2-Image (eigentlich ja im ext2-Image) ersetzen (damit da BB und Libs aus einem Build stammen), wäre aber m.E. nur die zweitbeste Lösung und eigentlich sollte der dynamische Loader das auch glattbügeln, was da event. an Unterschieden existiert.
Ein ganz anderer Ansatz wäre der Vergleich der /dev-Verzeichnisse bei einem originalen AVM-Image und bei dem von Freetz verwendeten Image für die yaffs2-Partition. Wie ich schon weiter vorne geschrieben habe, blicke ich beim Anlegen der Nodes unterhalb von /dev durch Freetz nicht wirklich durch (habe auch nicht den geringsten Ehrgeiz, dort ohne Not zu analysieren) und eine unglückliche Abweichung an dieser Stelle könnte ebenfalls zu Problemen führen ... schon wegen der anderen Arbeitsweise beim 06.50, wo das originale /dev-Verzeichnis per bind-Mount in das System nach dem pivot_root gemountet wird, während es vorher dort ein mount für ein tmpfs gab und die Nodes per tar-Kommando von dem einen Verzeichnis in das andere übertragen wurden. In dieser unterschiedlichen Behandlung könnte m.E. auch noch eine potentielle Stolperfalle für Freetz liegen.
Ich könnte sicherlich auch mal selbst ein Freetz-Image testen ... andererseits gebe ich zu, daß mein eigenes Interesse an einem solchen Image nahe Null liegt und ich das tatsächlich erst als allerletzten Schritt in Erwägung ziehen würde, wenn es keine irgendwie erklärlichen Ursachen mehr gibt. Ansonsten habe ich mit eigenen Tests genug zu tun ... und dabei hänge ich die Box selbst oft genug auf, aber eben erst später.
EDIT: Das "panic.log" ist ggf. nicht als char-Device in /var/flash vorhanden (und müßte angelegt werden), aber über das proc-Interface sollte es auch bei der 06.30 zugänglich sein ... allerdings löscht wohl ein Lesezugriff über das proc-Interface auch gleich den alten Inhalt und so sollte man diesen Lesezugriff gleich in eine Ausgabedatei umleiten. Das ist normalerweise im proc-FS unter /proc/avm_panic_cr und /proc/avm_panic_sd zugänglich (sind wohl auch tatsächlich dieselben Inhalte, zumindest bei der 06.50), bei mir gab es z.B. letztens ein Problem mit einer falschen Busybox bzw. einem fehlenden Symlink, wo dann kein "init" gefunden wurde, aber der eigentliche Fehler sollte schon das fehlgeschlagene Mounten für devtmpfs gewesen sein:
Code:
[ 6.220000] SQUASHFS error: Can't find a SQUASHFS superblock on mtdblock1
[ 6.230000] yaffs: dev is 32505857 name is "mtdblock1" ro
[ 6.240000] yaffs: passed flags ""
[ 6.240000] yaffs: yaffs: Attempting MTD mount of 31.1,"mtdblock1"
[ 6.240000] yaffs: auto selecting yaffs2
[ 6.310000] yaffs: yaffs_read_super: is_checkpointed 0
[ 6.310000] VFS: Mounted root (yaffs filesystem) readonly on device 31:1.
[ 6.320000] [COLOR="#FF0000"]devtmpfs: error mounting -2[/COLOR] => normal wäre "devtmpfs: mounted"
[ 6.320000] Freeing unused kernel memory: 300K (80835000 - 80880000)
[ 6.330000] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ich habe gerade mal zum Spaß (parallel zur NFL) mit Freetz eine uClibc gebaut und nur mal die Symbole der libuClibc mit der originalen Lib von AVM verglichen ... da fehlen einige Funktionen in der Freetz-Variante (die Adressen wurden weggeschnitten und nur die Namen und Typen der Symbole sortiert und dann mit "diff" verglichen):
Das braucht also erst einmal Puzzle-Arbeit mit dem Zusammensuchen aller möglichen Patches (z.B. dem für execvpe, der m.E. bisher im Freetz nicht vorhanden ist, jedenfalls finde ich ihn nicht) und der korrekten Einstellungen beim Bauen der uClibc (die fts_*-Funktionen brauchen z.B. UCLIBC_HAS_FTS=y) ... da ist sicherlich das Warten auf die AVM-OSS-Pakete die einfachere Lösung.
Ob tatsächlich die AVM-Module die "fehlenden Funktionen" überhaupt verwenden wollen, kann man natürlich auch noch versuchen zu ermitteln (solange das nicht mit dlopen() irgendwo dynamisch erfolgt) ... aber wenn da auch autoconf-Geschichten bei den AVM-Programmen umgesetzt sind und die sich an die vorhandenen Funktionen der uClibc anpassen, dann ist die Wahrscheinlichkeit dafür ja nicht so gering.
Ich kriegte jedenfalls nicht mal auf Anhieb eine dynamisch gelinkte "bash"-Version aus der Freetz-Toolchain (clean build) mit den AVM-Libraries zum Laufen und dabei braucht die außer der libc (das ist ja in Wahrheit die libuClibc), der libreadline und der libgcc eigentlich nichts weiter ... da stimmt also einiges bei der Freetz-Konfiguration der uClibc nicht mit der von AVM überein.
Ein paar wenige Änderungen (erst einmal nur an den Einstellungen der uClibc) reduzierten die Unterschiede dann schon erheblich:
Dafür habe ich die folgenden Änderungen gegenüber der "toolchain/make/target/uclibc/Config.0.9.33.2" aus dem Trunk verwendet (geändert bei mir über "make uclibc-menuconfig", aber das "svn diff"-File ist einfacher anzuwenden als irgendwelche Einstellungen zu beschreiben wären):
Falls sich also jemand berufen fühlt, könnte er/sie an dieser Stelle fortsetzen, es sind fehlen offenbar noch vier passende Patches, die man sich aus den Mailinglisten oder aus dem Git (am ehesten bei git.busybox.net) zusammensuchen muß.
https://git.busybox.net/uClibc/commit/?id=0eb30761a26c46aaf555464114851202ae9c27bd für execvpe
https://git.busybox.net/uClibc/commit/?id=42d1b23fc0f3748b8bf474e456d6c44aa7e563fd für mkostemp
https://git.busybox.net/uClibc/commit/?id=acb6d27b82aa8b38cb7222d454c8c203a055e1 für posix_madvise
https://git.busybox.net/uClibc/commit/?id=929b1a121c5ff0daa33b2107b4c1a68b650d93ee für rpmatch
Einzelne Pakete kann man natürlich trotzdem bauen und ggf. eben statisch linken oder die korrekten Libraries für die eigenen Programme in der Suchreihenfolge vor den AVM-Libs platzieren.
Aber ein komplettes Image, noch dazu mit Austausch der AVM-Libraries gegen selbst erstellte (die dann schon einen größeren Umfang haben sollten und keinen kleineren durch fehlende Funktionen), ist vermutlich erst mal noch eine Utopie ... ich denke schon, daß meine Vermutung mit der Bootschleife wegen des Austauschs der Libraries im yaffs2-Dateisystem (bzw. im ext2-Image von Freetz) nicht so abwegig ist.
Gehet hin und nervt AVM ... auf daß die OSS-Pakete für die 113.06.50 freigegeben werden.
Ohne die ist es eine Sisyphusarbeit (auch wenn man wohl irgendwann doch fertig werden würde im Gegensatz zum "sagenhaften" Namensgeber) und die wird sich sicherlich niemand aufbürden wollen.
Ich jedenfalls nicht ... da ich ohnehin nur die originale Firmware mit Zusätzen versehe und eher selten etwas austausche oder ersetze (eigentlich nie), brauche ich das einfach nicht und habe das mit der uClibc nur aus Spaß an der Freude mal etwas näher angesehen.
Code:
--- original.sorted 2015-12-20 20:11:21.022338411 +0100
+++ modified.sorted 2015-12-20 20:11:42.498337500 +0100
@@ -34,7 +34,7 @@
brk T
bsd_signal T
bsearch T
-__bss_start S
+__bss_start A
btowc T
bzero T
cachectl T
@@ -94,12 +94,9 @@
ctermid T
ctime_r T
ctime T
-__ctype_b_loc T
-__ctype_tolower_loc T
-__ctype_toupper_loc T
-__curlocale_set W
-__curlocale_var D
-__curlocale W
+__ctype_b D
+__ctype_tolower D
+__ctype_toupper D
cuserid T
__cxa_atexit T
__cxa_finalize T
@@ -126,11 +123,10 @@
__dso_handle w
dup2 T
dup3 T
-duplocale T
dup T
dysize T
-_edata D
-_end B
+_edata A
+_end A
endgrent T
endhostent T
endmntent T
@@ -143,6 +139,7 @@
endttyent T
endusershell T
endutent T
+endutxent T
__environ B
environ V
epoll_create1 T
@@ -153,7 +150,7 @@
erand48_r T
erand48 T
errno B
-__errno_location W
+__errno_location T
error_at_line W
error_message_count B
error_one_per_line S
@@ -173,14 +170,15 @@
execlp T
execl T
execve T
-execvpe T
execvp T
execv T
_exit T
exit T
_Exit W
faccessat T
-_fbss S
+fallocate64 T
+fallocate T
+_fbss A
__fbufsize T
fchdir T
fchmodat T
@@ -257,7 +255,6 @@
fread_unlocked T
freeaddrinfo T
freeifaddrs T
-freelocale T
free T
fremovexattr T
freopen64 T
@@ -288,11 +285,6 @@
ftruncate64 T
ftruncate T
ftrylockfile T
-fts_children T
-fts_close T
-fts_open T
-fts_read T
-fts_set T
ftw64 T
ftw T
funlockfile T
@@ -417,6 +409,11 @@
getutent T
getutid T
getutline T
+getutmp T
+getutmpx T
+getutxent T
+getutxid T
+getutxline T
getwchar T
getwchar_unlocked T
getwc T
@@ -432,6 +429,7 @@
glob T
gmtime_r T
gmtime T
+_gp A
grantpt T
hasmntopt T
hcreate_r T
@@ -482,71 +480,33 @@
ioperm T
iopl T
iruserok T
-__isalnum_l T
-isalnum_l T
isalnum T
-__isalpha_l T
-isalpha_l T
isalpha T
-isascii_l T
isascii T
isatty T
-__isblank_l T
-isblank_l T
isblank T
-__iscntrl_l T
-iscntrl_l T
iscntrl T
isctype T
-__isdigit_l T
-isdigit_l T
isdigit T
-__isgraph_l T
-isgraph_l T
isgraph T
-__islower_l T
-islower_l T
islower T
-__isprint_l T
-isprint_l T
isprint T
-__ispunct_l T
-ispunct_l T
ispunct T
-__isspace_l T
-isspace_l T
isspace T
-__isupper_l T
-isupper_l T
isupper T
-iswalnum_l T
iswalnum T
-iswalpha_l T
iswalpha T
-iswblank_l T
iswblank T
-iswcntrl_l T
iswcntrl T
-iswctype_l T
iswctype T
-iswdigit_l T
iswdigit T
-iswgraph_l T
iswgraph T
-iswlower_l T
iswlower T
-iswprint_l T
iswprint T
-iswpunct_l T
iswpunct T
-iswspace_l T
iswspace T
-iswupper_l T
iswupper T
-iswxdigit_l T
iswxdigit T
-__isxdigit_l T
-isxdigit_l T
isxdigit T
__ivaliduser T
jrand48_r T
@@ -661,8 +621,6 @@
mkfifo T
mknodat T
mknod T
-mkostemp64 T
-mkostemp T
mkstemp64 T
mkstemp T
mktemp T
@@ -686,11 +644,9 @@
munlock T
munmap T
nanosleep W
-newlocale T
nftw64 T
nftw T
nice T
-nl_langinfo_l T
nl_langinfo T
nrand48_r T
nrand48 T
@@ -736,6 +692,7 @@
optind D
optopt D
__pagesize B
+parse_printf_format T
pathconf T
pause W
pclose T
@@ -755,7 +712,6 @@
posix_fadvise T
posix_fallocate64 T
posix_fallocate T
-posix_madvise T
posix_memalign T
posix_openpt T
ppoll T
@@ -827,6 +783,7 @@
putspent T
puts T
pututline T
+pututxline T
putwchar T
putwchar_unlocked T
putwc T
@@ -871,6 +828,7 @@
regexec T
regfree T
__register_atfork T
+register_printf_function T
registerrpc T
remap_file_pages T
re_match_2 T
@@ -881,7 +839,6 @@
remque T
renameat T
rename T
-__res_close T
re_search_2 T
re_search T
re_set_registers T
@@ -910,7 +867,6 @@
__rpc_thread_svc_fdset T
__rpc_thread_svc_max_pollfd T
__rpc_thread_svc_pollfd T
-rpmatch T
rresvport T
rtime T
ruserok T
@@ -990,6 +946,7 @@
setuid T
setusershell T
setutent T
+setutxent T
setvbuf T
setxattr T
sgetspent_r T
@@ -1010,8 +967,6 @@
sigemptyset T
sigfillset T
siggetmask T
-sighold T
-sigignore T
siginterrupt T
sigisemptyset T
__sigismember T
@@ -1025,11 +980,9 @@
sigpending T
sigprocmask T
sigqueue T
-sigrelse T
__sigsetjmp_aux T
__sigsetjmp T
sigsetmask T
-sigset T
sigsuspend T
sigtimedwait W
sigwaitinfo W
@@ -1067,26 +1020,22 @@
stime T
stpcpy T
stpncpy T
-strcasecmp_l T
strcasecmp T
strcasestr T
strcat T
strchrnul T
strchr W
strcmp W
-strcoll_l T
strcoll T
strcpy T
strcspn T
strdup W
strerror_r W
strerror T
-strftime_l T
strftime T
strlcat T
strlcpy T
strlen W
-strncasecmp_l T
strncasecmp T
strncat T
strncmp W
@@ -1094,35 +1043,26 @@
strndup T
strnlen T
strpbrk T
-strptime_l T
strptime T
strrchr W
strsep T
strsignal T
strspn T
strstr T
-strtod_l T
strtod T
-strtof_l T
strtof T
strtoimax T
strtok_r T
strtok T
-strtold_l T
strtold T
-strtoll_l T
-strtol_l T
strtoll T
strtol T
strtoq T
-strtoull_l T
-strtoul_l T
strtoull T
strtoul T
strtoumax T
strtouq T
strverscmp T
-strxfrm_l T
strxfrm T
svcerr_auth T
svcerr_decode T
@@ -1168,8 +1108,6 @@
syslog T
sysmips T
system W
-__sysv_signal T
-sysv_signal T
tcdrain W
tcflow T
tcflush T
@@ -1201,17 +1139,11 @@
tmpfile T
tmpnam_r T
tmpnam T
-toascii_l T
toascii T
-tolower_l T
tolower T
-toupper_l T
toupper T
-towctrans_l T
towctrans T
-towlower_l T
towlower T
-towupper_l T
towupper T
truncate64 T
truncate T
@@ -1241,13 +1173,13 @@
unsetenv T
unshare T
updwtmp T
-uselocale T
+updwtmpx T
usleep T
-ustat T
utimensat T
utimes T
utime T
utmpname T
+utmpxname T
valloc T
vasprintf T
vdprintf T
@@ -1287,21 +1219,17 @@
wcpcpy T
wcpncpy T
wcrtomb T
-wcscasecmp_l T
wcscasecmp T
wcscat T
wcschrnul T
wcschr T
wcscmp T
-wcscoll_l T
wcscoll T
wcscpy T
wcscspn T
wcsdup T
-wcsftime_l T
wcsftime T
wcslen W
-wcsncasecmp_l T
wcsncasecmp T
wcsncat T
wcsncmp T
@@ -1313,35 +1241,25 @@
wcsrtombs T
wcsspn T
wcsstr T
-wcstod_l T
wcstod T
-wcstof_l T
wcstof T
wcstoimax T
wcstok T
-wcstold_l T
wcstold T
-wcstoll_l T
-wcstol_l T
wcstoll T
wcstol T
wcstombs T
wcstoq T
-wcstoull_l T
-wcstoul_l T
wcstoull T
wcstoul T
wcstoumax T
wcstouq T
wcswcs T
wcswidth T
-wcsxfrm_l T
wcsxfrm T
wctob T
wctomb T
-wctrans_l T
wctrans T
-wctype_l T
wctype T
wcwidth T
wmemchr TOb tatsächlich die AVM-Module die "fehlenden Funktionen" überhaupt verwenden wollen, kann man natürlich auch noch versuchen zu ermitteln (solange das nicht mit dlopen() irgendwo dynamisch erfolgt) ... aber wenn da auch autoconf-Geschichten bei den AVM-Programmen umgesetzt sind und die sich an die vorhandenen Funktionen der uClibc anpassen, dann ist die Wahrscheinlichkeit dafür ja nicht so gering.
Ich kriegte jedenfalls nicht mal auf Anhieb eine dynamisch gelinkte "bash"-Version aus der Freetz-Toolchain (clean build) mit den AVM-Libraries zum Laufen und dabei braucht die außer der libc (das ist ja in Wahrheit die libuClibc), der libreadline und der libgcc eigentlich nichts weiter ... da stimmt also einiges bei der Freetz-Konfiguration der uClibc nicht mit der von AVM überein.
Ein paar wenige Änderungen (erst einmal nur an den Einstellungen der uClibc) reduzierten die Unterschiede dann schon erheblich:
Code:
--- original.sorted 2015-12-20 21:32:05.578133072 +0100
+++ modified.sorted 2015-12-20 22:57:39.377915475 +0100
@@ -34,7 +34,7 @@
brk T
bsd_signal T
bsearch T
-__bss_start S
+__bss_start A
btowc T
bzero T
cachectl T
@@ -129,8 +129,8 @@
duplocale T
dup T
dysize T
-_edata D
-_end B
+_edata A
+_end A
endgrent T
endhostent T
endmntent T
@@ -143,6 +143,7 @@
endttyent T
endusershell T
endutent T
+endutxent T
__environ B
environ V
epoll_create1 T
@@ -153,7 +154,7 @@
erand48_r T
erand48 T
errno B
-__errno_location W
+__errno_location T
error_at_line W
error_message_count B
error_one_per_line S
@@ -173,14 +174,15 @@
execlp T
execl T
execve T
-execvpe T
execvp T
execv T
_exit T
exit T
_Exit W
faccessat T
-_fbss S
+fallocate64 T
+fallocate T
+_fbss A
__fbufsize T
fchdir T
fchmodat T
@@ -417,6 +419,11 @@
getutent T
getutid T
getutline T
+getutmp T
+getutmpx T
+getutxent T
+getutxid T
+getutxline T
getwchar T
getwchar_unlocked T
getwc T
@@ -432,6 +439,7 @@
glob T
gmtime_r T
gmtime T
+_gp A
grantpt T
hasmntopt T
hcreate_r T
@@ -661,8 +669,6 @@
mkfifo T
mknodat T
mknod T
-mkostemp64 T
-mkostemp T
mkstemp64 T
mkstemp T
mktemp T
@@ -736,6 +742,7 @@
optind D
optopt D
__pagesize B
+parse_printf_format T
pathconf T
pause W
pclose T
@@ -755,7 +762,6 @@
posix_fadvise T
posix_fallocate64 T
posix_fallocate T
-posix_madvise T
posix_memalign T
posix_openpt T
ppoll T
@@ -827,6 +833,7 @@
putspent T
puts T
pututline T
+pututxline T
putwchar T
putwchar_unlocked T
putwc T
@@ -871,6 +878,7 @@
regexec T
regfree T
__register_atfork T
+register_printf_function T
registerrpc T
remap_file_pages T
re_match_2 T
@@ -910,7 +918,6 @@
__rpc_thread_svc_fdset T
__rpc_thread_svc_max_pollfd T
__rpc_thread_svc_pollfd T
-rpmatch T
rresvport T
rtime T
ruserok T
@@ -990,6 +997,7 @@
setuid T
setusershell T
setutent T
+setutxent T
setvbuf T
setxattr T
sgetspent_r T
@@ -1241,6 +1249,7 @@
unsetenv T
unshare T
updwtmp T
+updwtmpx T
uselocale T
usleep T
ustat T
@@ -1248,6 +1257,7 @@
utimes T
utime T
utmpname T
+utmpxname T
valloc T
vasprintf T
vdprintf T
Code:
Index: Config.0.9.33.2
===================================================================
--- Config.0.9.33.2 (revision 13504)
+++ Config.0.9.33.2 (working copy)
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Version: 0.9.33.2
-# Tue May 15 13:05:00 2012
+# Sun Dec 20 22:28:18 2015
#
# TARGET_alpha is not set
# TARGET_arm is not set
@@ -51,9 +51,9 @@
# Using ELF file format
#
ARCH_ANY_ENDIAN=y
-ARCH_LITTLE_ENDIAN=y
-# ARCH_WANTS_BIG_ENDIAN is not set
-ARCH_WANTS_LITTLE_ENDIAN=y
+ARCH_BIG_ENDIAN=y
+ARCH_WANTS_BIG_ENDIAN=y
+# ARCH_WANTS_LITTLE_ENDIAN is not set
ARCH_HAS_MMU=y
ARCH_USE_MMU=y
UCLIBC_HAS_FLOATS=y
@@ -85,10 +85,11 @@
UCLIBC_CTOR_DTOR=y
# LDSO_GNU_HASH_SUPPORT is not set
# HAS_NO_THREADS is not set
-LINUXTHREADS_OLD=y
+# LINUXTHREADS_OLD is not set
# LINUXTHREADS_NEW is not set
-# UCLIBC_HAS_THREADS_NATIVE is not set
+UCLIBC_HAS_THREADS_NATIVE=y
UCLIBC_HAS_THREADS=y
+UCLIBC_HAS_TLS=y
PTHREADS_DEBUG_SUPPORT=y
UCLIBC_HAS_SYSLOG=y
UCLIBC_HAS_LFS=y
@@ -133,10 +134,10 @@
UCLIBC_HAS_GNU_ERROR=y
UCLIBC_BSD_SPECIFIC=y
UCLIBC_HAS_BSD_ERR=y
-# UCLIBC_HAS_OBSOLETE_BSD_SIGNAL is not set
-# UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL is not set
+UCLIBC_HAS_OBSOLETE_BSD_SIGNAL=y
+UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL=y
# UCLIBC_NTP_LEGACY is not set
-# UCLIBC_SV4_DEPRECATED is not set
+UCLIBC_SV4_DEPRECATED=y
UCLIBC_HAS_REALTIME=y
UCLIBC_HAS_ADVANCED_REALTIME=y
UCLIBC_HAS_EPOLL=y
@@ -155,7 +156,7 @@
UCLIBC_HAS_REENTRANT_RPC=y
UCLIBC_USE_NETLINK=y
UCLIBC_SUPPORT_AI_ADDRCONFIG=y
-# UCLIBC_HAS_BSD_RES_CLOSE is not set
+UCLIBC_HAS_BSD_RES_CLOSE=y
UCLIBC_HAS_COMPAT_RES_STATE=y
# UCLIBC_HAS_EXTRA_COMPAT_RES_STATE is not set
UCLIBC_HAS_RESOLVER_SUPPORT=y
@@ -178,7 +179,7 @@
# UCLIBC_BUILD_MINIMAL_LOCALE is not set
UCLIBC_PREGENERATED_LOCALE_DATA=y
# UCLIBC_DOWNLOAD_PREGENERATED_LOCALE_DATA is not set
-# UCLIBC_HAS_XLOCALE is not set
+UCLIBC_HAS_XLOCALE=y
# UCLIBC_HAS_HEXADECIMAL_FLOATS is not set
# UCLIBC_HAS_GLIBC_DIGIT_GROUPING is not set
UCLIBC_HAS_GLIBC_CUSTOM_PRINTF=y
@@ -208,6 +209,7 @@
UCLIBC_HAS_SIGNUM_MESSAGES=y
# UCLIBC_HAS_SYS_SIGLIST is not set
UCLIBC_HAS_GNU_GETOPT=y
+UCLIBC_HAS_STDIO_FUTEXES=y
UCLIBC_HAS_GNU_GETSUBOPT=y
#
@@ -220,7 +222,7 @@
# UCLIBC_HAS_WORDEXP is not set
UCLIBC_HAS_NFTW=y
UCLIBC_HAS_FTW=y
-# UCLIBC_HAS_FTS is not set
+UCLIBC_HAS_FTS=y
UCLIBC_HAS_GLOB=y
# UCLIBC_HAS_GNU_GLOB is not set
UCLIBC_HAS_UTMPX=y
@@ -249,7 +251,6 @@
CROSS_COMPILER_PREFIX=""
UCLIBC_EXTRA_CFLAGS="-fno-builtin-memcpy -fno-builtin-memset"
# DODEBUG is not set
-# DODEBUG_PT is not set
# DOSTRIP is not set
# DOASSERTS is not set
# SUPPORT_LD_DEBUG is not sethttps://git.busybox.net/uClibc/commit/?id=0eb30761a26c46aaf555464114851202ae9c27bd für execvpe
https://git.busybox.net/uClibc/commit/?id=42d1b23fc0f3748b8bf474e456d6c44aa7e563fd für mkostemp
https://git.busybox.net/uClibc/commit/?id=acb6d27b82aa8b38cb7222d454c8c203a055e1 für posix_madvise
https://git.busybox.net/uClibc/commit/?id=929b1a121c5ff0daa33b2107b4c1a68b650d93ee für rpmatch
Einzelne Pakete kann man natürlich trotzdem bauen und ggf. eben statisch linken oder die korrekten Libraries für die eigenen Programme in der Suchreihenfolge vor den AVM-Libs platzieren.
Aber ein komplettes Image, noch dazu mit Austausch der AVM-Libraries gegen selbst erstellte (die dann schon einen größeren Umfang haben sollten und keinen kleineren durch fehlende Funktionen), ist vermutlich erst mal noch eine Utopie ... ich denke schon, daß meine Vermutung mit der Bootschleife wegen des Austauschs der Libraries im yaffs2-Dateisystem (bzw. im ext2-Image von Freetz) nicht so abwegig ist.
Gehet hin und nervt AVM ... auf daß die OSS-Pakete für die 113.06.50 freigegeben werden.
Ohne die ist es eine Sisyphusarbeit (auch wenn man wohl irgendwann doch fertig werden würde im Gegensatz zum "sagenhaften" Namensgeber) und die wird sich sicherlich niemand aufbürden wollen.
Ich jedenfalls nicht ... da ich ohnehin nur die originale Firmware mit Zusätzen versehe und eher selten etwas austausche oder ersetze (eigentlich nie), brauche ich das einfach nicht und habe das mit der uClibc nur aus Spaß an der Freude mal etwas näher angesehen.
Hallo,
wenn ich den Thread so verfolge, habe ich das Gefühl, das es nicht möglich ist, ein Freetz Image mit 6.5 zu erstellen und lauffähig auf der Box zu bekommen.
Mich würde interessieren, ob bei jemand ein Freetz Image mit 6.5 läift und die Box im Internet ist.
Grüße
Erik
wenn ich den Thread so verfolge, habe ich das Gefühl, das es nicht möglich ist, ein Freetz Image mit 6.5 zu erstellen und lauffähig auf der Box zu bekommen.
Mich würde interessieren, ob bei jemand ein Freetz Image mit 6.5 läift und die Box im Internet ist.
Grüße
Erik
Sollte das der Fall sein, hätte sich der/diejenige sicher hier gemeldet. Wenn du was sinnvolles machen möchtest, frag bei AVM nach, wann sie die OSS-Pakete bereit stellen.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ich habe mal die Patches bis zum Ende durchgezogen, dabei ist das File im Anhang herausgekommen. Das taugt natürlich für den Trunk nicht, dort braucht es sicherlich noch eine Unterscheidung zwischen 0.9.33.2_3.10.73 und 0.9.33.2 mit dem Rest der Kernelversionen von AVM.
Aber man kann es auf einen ausgecheckten Trunk anwenden und dann (nach einem kompletten "distclean", weil m.W. die uClibc nirgendwo als (automatische) Abhängigkeit konfiguriert ist) neu übersetzen ... ob sich das damit erzeugte Freetz-Image dann auch starten läßt, habe ich aber noch nicht probieren können, bei mir läuft noch der komplette Build mit dem Patch - der ist gerade erst bei der Toolchain, weil ich selbst auch noch einmal ein "make distclean" gemacht habe, nachdem die erzeugte uClibc erst einmal richtig aussah.
Aber man kann es auf einen ausgecheckten Trunk anwenden und dann (nach einem kompletten "distclean", weil m.W. die uClibc nirgendwo als (automatische) Abhängigkeit konfiguriert ist) neu übersetzen ... ob sich das damit erzeugte Freetz-Image dann auch starten läßt, habe ich aber noch nicht probieren können, bei mir läuft noch der komplette Build mit dem Patch - der ist gerade erst bei der Toolchain, weil ich selbst auch noch einmal ein "make distclean" gemacht habe, nachdem die erzeugte uClibc erst einmal richtig aussah.
Leider kann ich gerade nicht frisch auschecken da freetz.org scheinbar down ist... Ich hab auf meinen Trunk von vorgestern deinen patch angewendet und danach distclean gemacht. Leider gehts danach nicht mehr:
Code:
----------------------------------------------------------------------
applying patch file toolchain/make/target/uclibc/0.9.33.2/995-execvpe.patch
patching file include/unistd.h
patching file libc/unistd/exec.c
patching file libc/unistd/execvpe.c
patching file include/unistd.h
Hunk #1 succeeded at 578 with fuzz 2 (offset 8 lines).
patching file libc/unistd/exec.c
Hunk #1 FAILED at 32.
Hunk #2 FAILED at 58.
Hunk #3 FAILED at 219.
Hunk #4 FAILED at 245.
Hunk #5 FAILED at 254.
Hunk #6 FAILED at 277.
Hunk #7 FAILED at 300.
Hunk #8 FAILED at 325.
8 out of 8 hunks FAILED -- saving rejects to file libc/unistd/exec.c.rej
The next patch would create the file libc/unistd/execvpe.c,
which already exists! Applying it anyway.
patching file libc/unistd/execvpe.c
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file libc/unistd/execvpe.c.rej
----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file toolchain/make/target/uclibc/0.9.33.2/995-execvpe.patch
make: *** [/fritz/7490/testbox/source/toolchain-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/uClibc-0.9.33.2/.unpacked] Error 2PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ja, ich kann jedem nur raten, sich bei der nächsten Gelegenheit einen "frischen Trunk" mal beiseite zu legen ... wenn niemand etwas unternimmt in den nächsten drei Wochen, könnte es eng werden für freetz.org.
Wenn Du mal "make uclibc-dirclean" machst und anschließend ein "make uclibc-unpacked", dann sollte eigentlich aus einer frisch entpackten uClibc-Version mit dem Patch (ich habe den nur per "svn diff" aus meiner Trunk-Kopie erzeugt) eine funktionsfähige Ausgangsbasis erstellt werden.
Kann es sein, daß da zweimal der Patch angewendet werden sollte? Das "The next patch would create the file libc/unistd/execvpe.c, which already exists! Applying it anyway." klingt mir danach ... eigentlich sollte es die execvpe.c nicht bereits geben. Ich habe gegen die 13504 "gearbeitet":
und da war m.E. kein Patch für execvpe dabei, also kann die Datei nicht existieren.
Wenn Du mal "make uclibc-dirclean" machst und anschließend ein "make uclibc-unpacked", dann sollte eigentlich aus einer frisch entpackten uClibc-Version mit dem Patch (ich habe den nur per "svn diff" aus meiner Trunk-Kopie erzeugt) eine funktionsfähige Ausgangsbasis erstellt werden.
Kann es sein, daß da zweimal der Patch angewendet werden sollte? Das "The next patch would create the file libc/unistd/execvpe.c, which already exists! Applying it anyway." klingt mir danach ... eigentlich sollte es die execvpe.c nicht bereits geben. Ich habe gegen die 13504 "gearbeitet":
Code:
$ svn info
Path: .
Working Copy Root Path: /home/user/trunk
URL: http://svn.freetz.org/trunk
Relative URL: ^/trunk
Repository Root: http://svn.freetz.org
Repository UUID: 149334a1-2f27-0410-a3b9-fc62619ac1e6
Revision: 13504
Node Kind: directory
Schedule: normal
Last Changed Author: er13
Last Changed Rev: 13504
Last Changed Date: 2015-12-13 17:42:58 +0100 (Sun, 13 Dec 2015)PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Wobei der SVN-Service auf freetz.org nach meinem Icinga-Server seit 17:05 Uhr wieder verfügbar sein sollte ...
EDIT: Ich habe gerade noch ein checkout für die 13510 gemacht ... im Moment geht SVN also, Trac aber nicht.
EDIT: Ich habe gerade noch ein checkout für die 13510 gemacht ... im Moment geht SVN also, Trac aber nicht.
Zuletzt bearbeitet:
Hu? Wieso eng werden?
Und ja SVN läuft wieder, mache gerade nen neuen checkout und werde dann mal den patch testen.
Edit: ist leider während des checkouts wieder down... Daher doch kein frischer Trunk.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Nicht mein Tisch, da die Pferde scheu zu machen ... da sollen sich die Leute vom Freetz-Hosting und/oder -Development zu äußern. Ich bin quasi nur noch aus Versehen in der Mailing-Liste und will keine Schweine durch die Gemarkung treiben.
Den Tipp, sich vorsichtshalber jeden Trunk auch unverändert noch einmal auf die Seite zu legen, halte ich erst einmal aufrecht.
Wenn mal SVN nicht funktionieren sollte, ist aber i.d.R. auch der Trunk auf github verfügbar (https://github.com/olistudent/freetz, im Moment sogar schon die 13510 mit den Änderungen von Whoopie synchronisiert) und der sollte relativ zeitnah auch jeweils aktualisiert werden. Wenn also der vServer mit Trac und SVN nicht verfügbar sein sollte, kann man auch auf git zurückgreifen - zumindest wird der Server bei github.com eher keine Probleme haben/kriegen. Insofern ist das ohnehin die bessere/modernere Alternative.
Am einfachsten ist das Erzeugen einer kompletten Kopie (wenn man keine Änderungen zurückschreiben will) mit:
Code:
mkdir fritzbox
cd fritzbox
git init
git clone https://github.com/olistudent/freetz trunkMelde erfolgreichen Start:
Auf nem sauberen trunk ging der Patch ohne Probleme und die Box ist wie zu sehen richtig hochgefahren. Da ich erstmal nur minimal wie möglich gebaut habe kann ich noch nix zu weiteren Programmen sagen die laufen/nicht laufen (ausser dropbear
) - aber zumindest kommt die 06.50 so sauber hoch.
Code:
Firmware: 113.06.50 rev32007
Freetz: devel-13510MAuf nem sauberen trunk ging der Patch ohne Probleme und die Box ist wie zu sehen richtig hochgefahren. Da ich erstmal nur minimal wie möglich gebaut habe kann ich noch nix zu weiteren Programmen sagen die laufen/nicht laufen (ausser dropbear
) - aber zumindest kommt die 06.50 so sauber hoch.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Dann war mein Verdacht mit der unpassenden uClibc wohl richtig ... für den Kernel fange ich aber nicht mit weiteren Versuchen an, das hat sicherlich tatsächlich Zeit, bis AVM die Quellen rausrückt.
@er13: Wie geschrieben, das war/ist nur ein "quick&dirty"-Hack (beim Football-Sehen) meinerseits, der in keinster Weise berücksichtigt, daß die 0.9.33.2 bei früheren Versionen mit anderen Funktionen gebraucht wird und daß sich durch die abweichenden Einstellungen für die uClibc auch die Namen von Funktionen ändern (siehe erstes Listing in #66). Ich glaube nicht, daß es möglich sein wird, aus einer einheitlichen Konfiguration für die uClibc 0.9.33.2 sowohl die Version für 2.6-Kernel als auch die für 3.10-Kernel (AVM-kompatibel) zu bauen. Da Du vermutlich ohnehin Deine eigenen Vorstellungen hast, wie Du das umsetzen willst, hake ich das Thema für mich hier erst einmal ab ...
@er13: Wie geschrieben, das war/ist nur ein "quick&dirty"-Hack (beim Football-Sehen) meinerseits, der in keinster Weise berücksichtigt, daß die 0.9.33.2 bei früheren Versionen mit anderen Funktionen gebraucht wird und daß sich durch die abweichenden Einstellungen für die uClibc auch die Namen von Funktionen ändern (siehe erstes Listing in #66). Ich glaube nicht, daß es möglich sein wird, aus einer einheitlichen Konfiguration für die uClibc 0.9.33.2 sowohl die Version für 2.6-Kernel als auch die für 3.10-Kernel (AVM-kompatibel) zu bauen. Da Du vermutlich ohnehin Deine eigenen Vorstellungen hast, wie Du das umsetzen willst, hake ich das Thema für mich hier erst einmal ab ...
Was Freetz betrifft, bin ich eher ein absolutes Greenhorn - ich habe es bisher benutzt (bis Firmware 6.25 auf der 7490 - danach habe ich erstmal nicht neuere Firmwares installiert), um per Patch die debug.cfg wieder zu aktivieren, um den LCR-Router weiter verwenden zu können.
Hierzu ist ja nur das Entpacken und Packen der Original-Firmware mit fwmod notwendig - dazwischen wird dann nur die rc.tail.sh gepatched.
Kann mir schon jemand sagen, ob hierbei ebenfalls wie beim kompletten Freetz-Build mit den hier im Thread beschriebenen Problemen zu rechnen ist, oder sollte die wieder gepackte Firmware ohne weitere Probleme laufen?
Danke,
Markus
Hierzu ist ja nur das Entpacken und Packen der Original-Firmware mit fwmod notwendig - dazwischen wird dann nur die rc.tail.sh gepatched.
Kann mir schon jemand sagen, ob hierbei ebenfalls wie beim kompletten Freetz-Build mit den hier im Thread beschriebenen Problemen zu rechnen ist, oder sollte die wieder gepackte Firmware ohne weitere Probleme laufen?
Danke,
Markus
Was mir aufgefallen ist (werde ich vielleicht nach den Feiertagen mal genauer nachstellen mit der Testbox) als ich gerade eben mal die Produktivbox kurz hochgehievt hab und direkt wieder zurück bin:
- Es ist kein Downgrade von 06.50 auf 06.30 per freetz möglich (auch nicht mit dem allow downgrade schalter)
- Mein WLAN funktionierte nicht. Schnelles blinken der WLAN LED, im Menu war es ausgegraut aber nicht deaktiviert. Ein Klick auf übernehmen führt zur deaktivierung (also die Unterpunkte Gastnetz etc.. verschwinden) - WLAN auf der Box macht die LED wieder in den Blinkmodus, WLAN wird aber nicht aufgebaut
- Mein USB-Stick wird erkannt aber nicht gemountet. Ist vfat - also nix Linux mäßiges eigentlich.
Ich habe derzeit keine Ahnung (mangels Zeit gerade) ob es an Freetz liegt oder ob es mit der Stock auch passiert - das nur als Hinweis falls auch jemand über etwas in der Richtung stolpern sollte
- Es ist kein Downgrade von 06.50 auf 06.30 per freetz möglich (auch nicht mit dem allow downgrade schalter)
Code:
Ausführen des Firmware-Installationsskripts /var/install ...
install: updating Kernel '3.10.73' is not supported - abort Update
ERLEDIGT – Rückgabewert des Installationsskripts: 7 (INSTALL_FIRMWARE_VERSION)- Mein USB-Stick wird erkannt aber nicht gemountet. Ist vfat - also nix Linux mäßiges eigentlich.
Ich habe derzeit keine Ahnung (mangels Zeit gerade) ob es an Freetz liegt oder ob es mit der Stock auch passiert - das nur als Hinweis falls auch jemand über etwas in der Richtung stolpern sollte
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Das geht inzwischen viel einfacher als mit "fwmod" ... zumindest für Windows-Benutzer - behaupte ich mal kühn, weil man die ansonsten notwendige Linux-Installation nicht braucht.
http://www.ip-phone-forum.de/showthread.php?t=273304
Erweckt dann auch gleich noch den Telnet-Daemon wieder zum Leben, wenn man den über die Telefoncodes ein- und ausschalten will - kann man auch auf die debug.cfg beschränken, wenn man verstanden hat, wie es funktioniert.
@vice_pres:
Das WLAN-Problem hatte ich auch mit den letzten Labor-Versionen und der ersten 06.50 - auch ohne Freetz ... was es am Ende tatsächlich war, weiß ich bis heute nicht genau.
Nach mehrmaligem Werksreset mit der originalen 06.50 (nur Telnet aktiviert per modfs) ging es dann auch dort ... dann habe ich nur noch ein cfgtakeover von der 06.30 gemacht (die WLAN-Einstellungen hat die Box gar nicht erst angeboten für die Übernahme) und seitdem ist das WLAN nicht totzukriegen.
Ich finde allerdings in den Konfigurationsdateien auch keinen richtigen Unterschied ... vielleicht wird das integrierte EEPROM der WLAN-Adapter tatsächlich anders genutzt bei den verschiedenen Kernel-Versionen und WLAN-Treibern.
Das habe ich unter "passiert" abgehakt ... war nur etwas Aufwand, das wieder hinzubiegen, weil alles in kleinen Schritten von einer voll modifizierten Box in Richtung auf immer weniger Änderungen von mir ausgeführt wurde. Hätte ich das rechtzeitig gewußt/geahnt, hätte ich gleich mit Werksreset angefangen ... wobei ich das Recovery-Programm gar nicht verwendet habe.
Das mit dem Downgrade ist normal, das wird ja nach wie vor von /var/install getestet, da macht Freetz nichts am Skript und das ist bei AVM nicht vorgesehen.
http://www.ip-phone-forum.de/showthread.php?t=273304
Erweckt dann auch gleich noch den Telnet-Daemon wieder zum Leben, wenn man den über die Telefoncodes ein- und ausschalten will - kann man auch auf die debug.cfg beschränken, wenn man verstanden hat, wie es funktioniert.
@vice_pres:
Das WLAN-Problem hatte ich auch mit den letzten Labor-Versionen und der ersten 06.50 - auch ohne Freetz ... was es am Ende tatsächlich war, weiß ich bis heute nicht genau.
Nach mehrmaligem Werksreset mit der originalen 06.50 (nur Telnet aktiviert per modfs) ging es dann auch dort ... dann habe ich nur noch ein cfgtakeover von der 06.30 gemacht (die WLAN-Einstellungen hat die Box gar nicht erst angeboten für die Übernahme) und seitdem ist das WLAN nicht totzukriegen.
Ich finde allerdings in den Konfigurationsdateien auch keinen richtigen Unterschied ... vielleicht wird das integrierte EEPROM der WLAN-Adapter tatsächlich anders genutzt bei den verschiedenen Kernel-Versionen und WLAN-Treibern.
Das habe ich unter "passiert" abgehakt ... war nur etwas Aufwand, das wieder hinzubiegen, weil alles in kleinen Schritten von einer voll modifizierten Box in Richtung auf immer weniger Änderungen von mir ausgeführt wurde. Hätte ich das rechtzeitig gewußt/geahnt, hätte ich gleich mit Werksreset angefangen ... wobei ich das Recovery-Programm gar nicht verwendet habe.
Das mit dem Downgrade ist normal, das wird ja nach wie vor von /var/install getestet, da macht Freetz nichts am Skript und das ist bei AVM nicht vorgesehen.
Zuletzt bearbeitet:
Hallo Peter,
zunächst mal vielen Dank, dass Du Dich trotz einiger Meinungsverschiedenheiten mit dem Thema beschäftigst und damit die Unterstützung von Fritz!OS 6.5x in Freetz voran bringst.
Ich habe versucht den unten zitierten Post von Dir zu verstehen und habe folgende Anmerkungen.
Unter der Annahme, dass diese Aussage richtig ist, kann ich Deine Überlegungen nachvollziehen. Es macht keinen Sinn auf 256 aufzufüllen, wenn es eigentlich auf 1024 aufgefüllt werden müsste.
Sollte die Aussage im allgemeinen (eventuell aber rein theortischen) Fall doch nicht richtig sein, so macht dieses Auffüllen auf 256 auf den ersten Blick noch weniger Sinn... Es sein denn, es ist irgendein komischer "Wunsch" von mount (z.B. ein Dateisystem-Image muss immer ein vielfaches von 256 sein). Aber die Tatsache, dass AVM es ausgerechnet mit 256 Dummy-Bytes prefixt (i.e. mit derselben Zahl, die mount "wünscht"), macht diese Theorie weniger wahrscheinlich.
Grüße,
Gene
zunächst mal vielen Dank, dass Du Dich trotz einiger Meinungsverschiedenheiten mit dem Thema beschäftigst und damit die Unterstützung von Fritz!OS 6.5x in Freetz voran bringst.
Ich habe versucht den unten zitierten Post von Dir zu verstehen und habe folgende Anmerkungen.
Da hat sich ein kleiner Testfehler eingeschlichen. Bei der Datei build/original/firmware/var/tmp/filesystem.image handelt es sich um eine Datei ohne Checksum, diese wird von fwmod in dieser Zeile entfernt. AVM's /var/install schneidet diese nicht ab, damit hat das originale filesystem.image von 7490.06.50 zum Flash-Zeitpunkt die Größe 0x1592008.
Diesen Teil habe ich so verstanden als möchtest Du sagen, dass aus der Tatsache, dass die Block-Größe des (EXT2)-Dateisystems X ist, immer folgt, dass die Größe des Dateisystem-Images immer ein vielfaches von X sein muss. Ist es wirklich so? Gibt es keine Ausnahmen/Sonderfälle, sparse-files z.B.
Unter der Annahme, dass diese Aussage richtig ist, kann ich Deine Überlegungen nachvollziehen. Es macht keinen Sinn auf 256 aufzufüllen, wenn es eigentlich auf 1024 aufgefüllt werden müsste.
Sollte die Aussage im allgemeinen (eventuell aber rein theortischen) Fall doch nicht richtig sein, so macht dieses Auffüllen auf 256 auf den ersten Blick noch weniger Sinn... Es sein denn, es ist irgendein komischer "Wunsch" von mount (z.B. ein Dateisystem-Image muss immer ein vielfaches von 256 sein). Aber die Tatsache, dass AVM es ausgerechnet mit 256 Dummy-Bytes prefixt (i.e. mit derselben Zahl, die mount "wünscht"), macht diese Theorie weniger wahrscheinlich.
Mount muss mit dem "gekürzten" Dateisystem-Image zurecht kommen. Wird der (letzte) unvollständige Block von mount irgendwie ignoriert (Vermutung), so könnten schon die Daten verloren gehen... theoretisch...
Grüße,
Gene
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,268
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Da hast Du vollkommen recht ... die Prüfsumme habe ich hier unterschlagen, daß sie bereits beim Entpacken des Images durch Freetz entfernt wird, war mir nicht bewußt und daß die /var/install von AVM die tatsächlich noch abtestet, genauso wenig (die habe ich eben schon sehr lange nicht mehr in Aktion erlebt
). Ich bin etwas irritiert, wozu dieser Mechanismus am Ende dienen soll - als Integritätsprüfung ist er für mich doppelt gemoppelt.Warum? (halb OT)
Bereits mit "firmwarecfg" wird ja die Struktur des tar-Files analysiert und nur die relevanten Teile in die Prüfung einbezogen, ein Fehler beim Download würde (m.E.) bereits dort zu einem Fehler führen, wenn ich da nicht ebenfalls Tests durcheinander geworfen habe. AVM erstellt die /var/signature auf der Basis eines "ganz normalen" tar-Archivs (ob unter Einschluß der leeren 1024 Byte am Ende oder nicht, lassen wir mal offen) und hängt dann diese Prüfsummendatei einfach noch an das Archiv korrekt an (also ab der Position des vorherigen Ende-Headers) mit dem 512-Byte-Header eines tar-Members, einer (ausgepackten) Länge von oktal 200 (128 Byte) und dem eigentlichen Dateiinhalt, aufgefüllt auf die Blocklänge eines tar-Files. Je nachdem, wie sie dort das Auffüllen dann ausführen:
, bringt das Auspacken auf der Box das berüchtigte "tar: short read" für den letzten Header oder auch nicht, dieser Fehler bringt auch - je nach Busybox-Version - unterschiedliche Exit-Codes. Träte jetzt ein Übertragungsfehler auf, würde schon die Signaturprüfung fehlschlagen, denn die beiden enthaltenen "image"-Files stehen natürlich schon vor der Signatur im äußeren "image"-File. Sollte ein Fehler beim Auspacken auftreten ("no space left" o.ä.), führt das zu einem Fehler bei dieser Operation. Wo da noch eine Verfälschung des Inhalts der "filesystem.image" auftreten sollte, sehe ich (schon wieder) nicht. Meines Erachtens werden auch die Prüfsummen schon lange nicht mehr für die Integritätsprüfung im Bootloader herangezogen (die CHECK-Kommandos im FTP arbeiten ja auch nicht mehr für NAND-Flash und auch bei den NOR-Modellen ist mit der Zusammenlegung von Kernel und FS-Image ja zumindest die "Einzelfallprüfung" nicht mehr möglich, abgesehen davon, daß da m.W. auch nicht auf die "erase size" korrigiert wird), bei der Methode der Übertragung der Dateien ins yaffs2-FS macht das auch keinen Sinn mehr, die (alte TI-)Prüfsumme wird ja gar nicht mitkopiert. Soviel als "Ausflug" zur Signatur-Bildung von AVM ... und meiner eigenen Meinung zu den TI-Prüfsummen und deren Verwendung.https://www.gnu.org/software/tar/manual/html_node/Standard.html schrieb:
Wobei ich eigentlich beim (hexadezimalen) Ansehen einer Image-Datei sogar die Signatur der Prüfsumme zu sehen glaubte am Ende (die ist ja sehr leicht zu identifizieren anhand der Abweichung von lauter Nullen beim Padding), aber da habe ich dann nicht auf die Offsets geachtet und habe wohl auch nicht das Freetz-Buildsystem ursprünglich verwendet, wie im Beitrag als Beispiel dann später beschrieben (damit das ein Leser 1:1 nachvollziehen kann). Langer Rede kurzer Sinn ... die
Aber ich sehe auch keine Abhängigkeit beim Mount von einem Vielfachen einer Blockgröße von 256 - bei keiner der bisher von mir verwendeten Methoden - und auch unter "historischen Aspekten" erschienen mir 256 Byte ziemlich unwahrscheinlich. Das geht bei der Sektorgröße der früheren Festplatten von 512 Byte schon los - hier könnte ich mir tatsächlich so ein Erfordernis erklären. Aber es besteht wohl nicht, wie u.a. die Arbeitsweise des hier erklärten Skripts zeigt, denn dort wird auch (in Abhängigkeit von den vorhandenen Utilities auf der FRITZ!Box) entweder mit "losetup" und Offset gemountet (ob da am Ende das loop-Device irgendwelches Padding macht, weiß ich nicht, wäre aber natürlich theoretisch möglich, warum aber dann wieder auf 256 Byte? mit einem solchen kurzen read() dürfte kein Dateisystem auf Blockebene zugreifen) oder auch mit dd (und ohne Padding) abgeschnitten. Anschließend wird in beiden Fällen gemountet und es hat m.W. bisher immer funktioniert.
Ich bleibe auch dabei, daß bei einer Annahme von Padding-Notwendigkeiten beim Lesen durch eine Dateisystem-Inkarnation ein Vielfaches von 256 nach wie vor nicht logisch wäre ... egal ob über ein loop-Device oder direkt von einem Block-Device gelesen wird, sollten das immer (Low-Level-)Zugriffe mit einem Vielfachen der Blocklänge des Dateisystems sein (oder zumindest der (ehemaligen) Sektorgröße einer HDD) und selbst wenn sich hinter dem letzten vom Dateisystem noch benutzten Block irgendwie "garbage" befindet, sollte da niemals eine Leseoperation stattfinden. So ein (ext2-)Filesystem muß ja auch in der "physikalischen Form" nicht den gesamten Datenträger (also die HDD-Partition) ausnutzen, da darf am Ende ungenutzter Platz verbleiben, auf den das Dateisystem nie zugreift und insofern hast Du es richtig verstanden, daß ich tatsächlich für ein solches Dateisystem (das nicht nur ein "virtuelles" in Image-Form ist, wie das SquashFS, wo jedes Byte zählt und eine "Hardware-Speicherung" nicht der primäre Verwendungszweck ist/war) die Behauptung aufstelle, daß der Code zur Verwaltung des Filesystems immer in Vielfachen der Blockgröße (oder zumindest der historischen Sektorgröße) lesen müßte und damit die 8 Byte von der Prüfsumme (die im Superblock ja nicht berücksichtigt sind) nie gelesen werden sollten. Nachdem das Mount-Kommando selbst und auch das loop-Device sich offensichtlich auch nicht daran stören, bleibt dieses 256-Byte-Padding für mich nach wie vor unklar ... ab 512 wäre das wieder etwas anderes, da müßte man dann ggf. im Code suchen.
Ich kann den Gedankengang nachvollziehen (und ich habe auch nicht in irgendwelchem Code gesucht, das möchte ich betonen - insofern ist das schon etwas spekulativ und nur empirisch überprüft mit dem o.a. "extract"-Skript und auch mit "modfs") ... aber m.E. macht es ja gar nichts, wenn "mount" den letzten Block tatsächlich ignorieren sollte, denn der ist ja gar kein Bestandteil des Dateisystems und wird nur hinten angeflascht. Solange der damit entstehende verkürzte zusätzliche Block nicht im Superblock hinzugefügt wird (und in den ggf. noch verteilt gespeicherten Kopien), sollte/darf das Dateisystem dort eigentlich nicht zugreifen wollen, so daß es m.E. keine Rolle spielen dürfte, wie sich "mount" selbst an dieser Stelle verhält (oder auch losetup bzw. das loop-Device, was ja aber von AVM gar nicht genutzt wird). Solange "mount" nicht direkt beim Einbinden abstürzt (was es offensichtlich nicht tut), sollte niemals auf den "chksum"-Block zugegriffen werden vom Filesystem-Treiber.
Das schließt allerdings (weil es eben reine Theorie ist) nicht aus, daß es doch vollkommen anders sein könnte ... daher hat für mich persönlich hier der direkte Test die entscheidende Aussage und der hat (für mich auf meiner beschränkten Test-Plattform 7490) bisher noch nie ein Problem mit dieser Prüfsumme ergeben. Da wäre es dann ohnehin für mich logischer, die 8 Byte am Ende auch noch abzuschneiden ... dann ist das Filesystem wieder in vollem Umfang "original".
Zuletzt bearbeitet:
Neueste Beiträge
-
Mitel 400 Private Kontakte nicht im Telefonbuch
- Letzte: Qbaah
-
-
Fritz!DECT 302 regelt nicht mehr
- Letzte: Base
-
[Sammlung] FRITZ!Smart Gateway - Labor/Inhaus 7.90 (Zyklus 'Smart24P1')- Letzte: Ralf-Fritz
-
[Sammlung] FRITZ!Smart Thermo 302 - Firmware 0.22 - 5.xx- Letzte: Jstessi
-
[Frage] Deutsche Giganetz und 5590 Fiber- Letzte: nschill
