Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Wir haben schon festgestellt, dass der Fehler am Update von squashfs von 3.3 auf 3.4 liegt. Da wurde ein "multithreaded" unsquashfs eingeführt, dass anscheinend ein Problem hat.
habe jetzt das stable 1.1 auf einem Laptop mit Mandriva PP 2007.0 laufen lassen und es ging ohne Fehlermeldungen durch.
Nachdem ich alles noch einmal habe mit 16MB Option (nachdem ich das anhand der HW Revision herausgefunden hatte) gemacht habe, konnte ich die Box problemlos aktualisieren.
Jetzt funktioniert nur das Passwort nicht. Bin ich zu blöd? Benutzer ist doch admin und Standardpasswort freetz, oder nicht?
Bitte dringend um Hilfe, danke.
ich hab den Fehler auch mit kubuntu 8.10 / 2.6.27.11...
Würde gern den trunk benutzen, da ich ein MT-D benutze und die letzte stable-FW keinen stabilen Betrieb für mich hergibt (Ton fällt komplett aus). Nachdem eine Meldung kam, ich solle bitte die firmware nach dl/fw/FRITZ.Box_Fon_WLAN_7270.Labor.54.04.70-13640.image kopieren und ich dieses getan habe, erhalte ich dann folgende Meldung beim kompilieren:
Wir haben schon festgestellt, dass der Fehler am Update von squashfs von 3.3 auf 3.4 liegt. Da wurde ein "multithreaded" unsquashfs eingeführt, dass anscheinend ein Problem hat.
Tatsächlich, hab mir stinkylinux nochma in eine VM auf meinem kubuntu gehauen und das ganze hat funktioniert. Das Compilieren hat aber ziemlich lang gedauert und kann einfach kein Dauerzustand bleiben. Ein Linux-System auf nem Linux-System macht in diesem Fall keinen Spaß!
Ist da jemand an ner Lösung dran?
Oder kann man das squashfs einfach downgraden? -Was wohl auch nicht im Sinne des Erfinders liegen würde...
Was mich nachträglich wundert ist, daß es bei vielen doch funktioniert hat. Insbesondere daß ein statisch kompiliertes Programm auf einem System gelaufen ist und auf einem anderen System nicht.
Wer sich den Patch genauer angeschaut hat, wird festgestellt haben, daß es ein Fehler beim Belegen des Speichers war, es wurde zu wenig Speicher angefordert für das, was nachher damit geschehen sollte.
Was mich nachträglich wundert ist, daß es bei vielen doch funktioniert hat. Insbesondere daß ein statisch kompiliertes Programm auf einem System gelaufen ist und auf einem anderen System nicht.
Ist eigentlich kein wunder. Denn unalliziierten Speicher nutzen ist immer ein Risikospiel. Kommt auf die lokalen Bedingungen an, wie mit dem Speicher umgegangen wird, genauso darauf, was vorher schon alels mit dem Rechenr passiert ist, etc. Kann gut gehen, muss nicht.
Bei einem statischen Programm gibt es nicht mehr viel, was zu Unterschieden führen kann. Das Einzige, was mir auf die Schnelle einfällt, ist die Auswahl der Speicherbereiche und in diesem Fall das Scheduling der einzelnen Threads, die vom verwendeten Kernel oder dessen Konfiguration abhängen können.